顯示具有 git 標籤的文章。 顯示所有文章
顯示具有 git 標籤的文章。 顯示所有文章

2023年9月20日 星期三

Windows 開發筆記 - 使用 Command Line / CMD / ssh 與 PHP 8.2 / Composer / Git / VIM 開發環境 @ Windows 11

幫同事看了一下 Windows 開發環境,要在此環境使用 PHP8.2 與 PHP Laravel v10 framework,由於之前採用 xampp 管理套件被環境變數卡住。這些問題描述,瞬間拉回到學生時代在那邊設置 Windows %PATH% 環境變數 XD 我也忘了那時在幹嘛?推論是配置 Java 環境吧

目前就把手邊的 Windows 11 筆電拿來遠端,但懶得打開它。並且實際在 command line 測試會碰到幾個問題。

1. 從 https://windows.php.net/download/ 下載 VS16 x64 Non Thread Safe ,並解壓在 C:\php 目錄中,必須在設置 php.ini 。想要知道自己的 php.ini 位置,可以用 php.exe --ini

C:\php>php.exe --ini 
Configuration File (php.ini) Path: 
Loaded Configuration File:         (none)
Scan for additional .ini files in: (none)
Additional .ini files parsed:      (none)

接著把 C:\php\php.ini-development 複製到 C:\php\php.ini 使用:

C:\php>copy php.ini-development php.ini     
複製了         1 個檔案。

後續就編輯 php.ini 開啟一些項目,在此就靠 C:\cygwin64\bin\vim.exe 當編輯器(若碰到滑鼠圈選文字難複製,記得關掉滑鼠模式 :set mouse-=a),主要打開一些 php.ini 註解:

; Directory in which the loadable extensions (modules) reside.
; https://php.net/extension-dir
;extension_dir = "./"
; On windows:
extension_dir = "ext"
; ...
extension=curl
extension=fileinfo
extension=gd
extension=intl
extension=mbstring
extension=exif
extension=mysqli
extension=openssl
extension=sqlite3

C:\php>php.exe --ini 
Configuration File (php.ini) Path: 
Loaded Configuration File:         C:\php\php.ini
Scan for additional .ini files in: (none)
Additional .ini files parsed:      (none)

2. 下載 composer 後,預設會失敗:

C:\php>php.exe composer.phar self-update

In Factory.php line 648:
                                                                                                                          The openssl extension is required for SSL/TLS protection but is not available. If you can not enable the openssl extension, you can   
   disable this error, at your own risk, by setting the 'disable-tls' option to true.                          

self-update [-r|--rollback] [--clean-backups] [--no-progress] [--update-keys] [--stable] [--preview] [--snapshot] [--1] [--2] [--2.2] [--set-channel-only] [--] [<version>]

設置後:

C:\php>php.exe composer.phar self-update 
You are already using the latest available Composer version 2.6.3 (stable channel).

3. 在管理專案時,透過 C:\php\php.exe composer.phar install 時,會需要 GIT 指令,解法就是去官方安裝一下,安裝完的目錄位置在 C:\Program Files\Git 位置

C:\>"C:\Program Files\Git\bin\git.exe" --version
git version 2.42.0.windows.2

4. 回過頭來,更新環境變數 %PATH% 

C:\>git
'git' 不是內部或外部命令、可執行的程式或批次檔。
C:\>echo %PATH%
C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\Docker\Docker\resources\bin;C:\WINDOWS\system32\config\systemprofile\AppData\Local\Microsoft\WindowsApps;C:\Users\user\AppData\Local\Microsoft\WindowsApps;
C:\>set PATH=%PATH%;C:\Program Files\Git\bin\
C:\>git --version
git version 2.42.0.windows.2

如此在 Windows 的 command line (PowerShell) 環境下,也可以靠純指令做一點事了

2022年8月8日 星期一

PHP 開發筆記 - 在 Windows 10 上配置 cmd line 開發環境


這個故事說來話長,我本身不會在 Windows 開發,但為了同事只好配置環境出來,交叉比對運作的問題。就筆記一下,這次要做的事就弄到純 cmd line 開發環境:

安裝:

如此,在 cmd 就可以靠純指令工作,像是 composer install ,而在 cmd line 中有 vim 編輯器,可以快速編輯小東西。

2020年2月19日 星期三

[Linux] 在 Ubuntu 重編 git 處理 error: gnutls_handshake() failed: A TLS fatal alert has been received @ Ubuntu 12.04

當使用 git clone https:// 來源時,會出現以下錯誤訊息:

error: gnutls_handshake() failed: A TLS fatal alert has been received. while accessing https://service/project.git/info/refs
fatal: HTTP request failed

解法就是重編 git (細節似乎是 gnutls 問題)

流程:
  1. 到 https://github.com/git/git/releases 下載 git 程式碼(此例用 v2.25.1)
  2. 安裝 libcurl4-openssl-dev libexpat1-dev 等編譯環境
  3. 編他:./configure --with-expat --with-curl --with-openssl
連續動作:

$ dpkg -l | grep gnutls
ii  libcurl3-gnutls                             7.22.0-3ubuntu4.17                      Multi-protocol file transfer library (GnuTLS)
ii  libgnutls-dev                               2.12.14-5ubuntu3.14                     GNU TLS library - development files
ii  libgnutls-openssl27                         2.12.14-5ubuntu3.14                     GNU TLS library - OpenSSL wrapper
ii  libgnutls26                                 2.12.14-5ubuntu3.14                     GNU TLS library - runtime library
ii  libgnutls26:i386                            2.12.14-5ubuntu3.14                     GNU TLS library - runtime library
ii  libgnutlsxx27                               2.12.14-5ubuntu3.14                     GNU TLS library - C++ runtime library
ii  libneon27-gnutls                            0.29.6-1ubuntu1                         HTTP and WebDAV client library (GnuTLS enabled)
$ sudo apt-get install libcurl4-openssl-dev tcl-dev libexpat1-dev
$ wget https://github.com/git/git/archive/v2.25.1.tar.gz
$ tar -xvf v2.25.1.tar.gz && cd git-v2.25.1
$ make configure
$ ./configure --with-expat --with-curl --with-openssl
$ make test
$ sudo make install


其中 make test 會跑一陣子,可以選擇執行 XD

2016年4月4日 星期一

透過 Git Submodule 和 CMake 使用 GoogleTest

大概兩年前有練習一下 [CPP] Unit Test for C++ Usage via Google Test,連假來複習一下,著重在 CMakefile 的使用:

$ cd /path/project
$ git submodule add https://github.com/google/googletest/tree/master/googletest 3rdParty/googletest

$ vim CMakeLists.txt
...

add_subdirectory(3rdParty/googletest)
add_executable(your_unit_test
your_unit_test.cpp
)
add_dependencies(your_unit_test gtest)
include_directories(${gtest_SOURCE_DIR}/include)
target_link_libraries(your_unit_test
gtest
)

2016年3月15日 星期二

AWS 筆記 - 使用 CodeCommit

AWS_CodeCommit_05

雖然很習慣自己架 git server ,但基於摸熟 AWS 服務,就小試一下。整個流程很簡單,建立一個 git repo 就輸入完名稱即可建立,接著提供 SSH / HTTPS 的存取方式。而特別的地方應該是 Triggers ,可以搭配以下四種 event 觸發動作,如簡訊寫信或HTTP endpoint (AWS SNS) 或是呼叫 AWS Lambda function 做事:

AWS_CodeCommit_06

其中以 AWS SNS 為例,還必須先去 AWS SNS 建立的對應服務才行,也能 Test trigger 一下,看起來是把資料都埋在 Message 裡頭:

{
  "Type" : "Notification",
  "MessageId" : "580672ce-b036-5484-b1ca-3daf00303ba3",
  "TopicArn" : "arn:aws:sns:us-east-1:HelloWorld",
  "Subject" : "TEST: AWS CodeCommit us-east-1 push: study-codecommit",
  "Message" : "{\"Records\":[{\"awsRegion\":\"us-east-1\",\"codecommit\":{\"references\":[{\"commit\":\"0000000000000000000000000000000000000000\",\"ref\":\"refs/heads/TestReference\"}]},\"customData\":\"codecommit\",\"eventId\":\"36e338ce-a719-4188-93bb-aa6c28298a71\",\"eventName\":\"TriggerEventTest\",...}]}",
  ...
}

2016年1月22日 星期五

DevOps 筆記 - Jenkins 處理 Git Submodule Authentication/Credential 問題

已經很習慣用 Bitbucket 做 git service,然後有個 project 裡有個 sub-project 一樣有存取控管,而 Jenkins 預設只有第一層存取時,可以正確透過 Credentials 來解決,但是 submodule 就會失敗。

依照原理解法有兩招:

  1. 直接在 Jenkins 執行者的 $HOME/.ssh/ 去撰寫底層 ssh 連線認證方式
  2. 使用 Jenkins plugin - SSH Agent Plugin

為了管理維護方便,當然就用 SSH Agent Plugin 啦,安裝完後,每一個 Project 就會多一個 SSH Agent 的設定選項,只需設定好即可。

另外,有一派會建議把原先 Jenkins Project 裡的 Git Credentials 去掉,一律都用 SSH Agent Plugin 的設定,但這招會導致後續要做 Git Publisher 要做 git tag 時產生問題。

2015年11月27日 星期五

DevOps 筆記 - 使用 Jenkins、Git、RPM、Ansible、Slack 建置持續整合架構(Continuous integration)

今天終於端出一盤比較好吃的菜了,用料有點雜筆記一下吧!之前已經用 Jenkins + Git + Slack 可以做到持續發布跟通知開發者了,但面對 AWS Auto Scaling 議題還是頗抖的,因為建立 AMI (Amazon Machine Image) 後,機器的狀態被保留在某一刻,這時服務量一大自動開啟機器時,就會出現服務更新的需求。原先同事採用 Puppet 方案,但仍不適合處理 Auto Scaling 的問題,因為 Puppet 需要比較強的關係式(Server/Client認證),雖然硬做也是 ok 的,但要一直維護 Server/Client 架構還是頗累,所幸有了 Ansible 的出現!這提供比較分散式的管理架構,Server 跟 Client 都是透過 keypair + ssh remote command 溝通的。

粗略配置作法:
  • Git
    • 主要特色還是 branch 的規劃,跟公司文化有關
      • master:正式網站的狀態
      • alpha:內部最新網站狀態
      • develop:最新程式碼
    • 開發者都是從 develop branch 開發服務,當有版本要釋出時,merge 進 alpha branch 後,發佈到 alpha site 測試,妥當後再把 alpha branch merge 進 master branch
      • 概念上有點從 develop -> alpha -> master 角度
      • 若有 hotfix 時,從 master 產生 branch 修正後,在 merge 回 alpha 跟 develop
      • 在 alpha site 測試出問題時,不斷地在 alpha branch 處理,到最後才 merge 回 develop branch,以及發佈到 master branch
    • 透過 Jenkins 每一次發版時,會下 git tag 標記狀態
      • develop-version-number
      • alpha-version-number
      • production-version-number
    • 相關資料:A successful Git branching model
  • Jenkins 
    • 新增 Slack Notification Plugin/Version Number Plug-In
    • 權限設定,為了不要暴露太多專案給開發者,做了簡易的權限管控
      • 設定全域安全性
        • 安全性領域:採用 Jenkins 內建使用者資料庫 且不允許註冊
        • 授權:採用專案型矩陣授權策略
          • 每一個 task 都可以自訂可以觀看的使用者
    • 管理方面,新增工作分成 build 跟 deploy 兩種
      • build 就是把 source code 包成 RPM ,方便作業系統管理和除錯追蹤,另外,對於開發者測試機的準備也有幫助
        • 取得最新程式碼後,透過 RPMBuild 包裝起來,擺至指定位置
        • 每一次 build 都會下 git tag 標記版本狀態,方便之後除錯
        • 若封裝過程可以接觸到 git 資訊,則把 source code 最後 3 筆 commit log 拉出來製作版本資訊
          • git log -3 --pretty=format:"{\"commit\":\"%H\",\"update\":\"%ad\",\"author\":\"%an\"}"
      • deploy 就是透過 ansible 進行發佈,因此也可以把 ansible 操作用 git 管理
        • 發布過程中,第一步先到指定位置找出最新的 RPM files
        • 第二部透過 AWS EC2 API 得知待更新機器列表
        • 透過 ssh remote command 進行機器更新
        • 盡量把所有動作濃縮至 Ansible command,而透過 Jenkins Web UI 撰寫幾個指令就好 
      • 工作通知
        • 每一次 build 或 deploy 都可以透過 slack plugin 將更新訊息發佈至指定頻道通知相關開發者
      • 採用輪詢 SCM 方式,由 Jenkins 主動確認程式碼狀態,以此決定是否出 build ,不採用 git hook 等被動方式進行工作任務
        • 無法規範開發者 git push 行為,擔心 push 太多造成大量 build event
      • build 完畢後,可以設立相關專案,自動進行 deploy 任務
  • AWS
    • 透過 AIM 建立一個只有 AmazonEC2ReadOnlyAccess 權限的帳號
    • 對於需被管理的機器,都透過 Tag 標記管理
      • 使用 AWS EC2 API 來動態查詢指定的機器,以此取得機器列表,例如指定 ELB 裡所有的機器
    • 關於 Auto Scaling
      • 由於機器 IP 非固定,在不同 data center 溝通容易踩到 Security Group 限制,建議還是把服務以 data center 切開
        • 例如有美西跟日本時,若 db server 開在美西,那需要存取此 db server 的機器就擺在美西就好,這樣 Security Group 比較好做(類似限制 LAN 即可)
  • Ansible
    • 將 RPM 複製到機器上安裝,在 Ubuntu server 可偷懶用 alien :P
    • 依照腳本,進行機器的環境配置,如 limits、web server 等
    • 埋入一個 boot script ,當開機時透過 ssh remote command 向 deploy server 要求更新自己
以上使用的相關資源:
  • RPM 打包目錄專用
    • https://github.com/changyy/rpm-builder
    • 若打包目錄有 .git 時,會抓出最後幾筆 commit log 塞進 version.json 檔案內,可協助往後的偵錯
    • 由於 RPMBuild 很吃環境變數,面對 Jenkins 同時出 build 會衝到共用資源的部分,在此已經透過修改 $HOME 目錄來避開共用資源的問題,因此不用再擔心 Jenkins 一次只能出一個 build
  • AWS EC2 機器查詢
    • http://docs.ansible.com/ansible/intro_dynamic_inventory.html#example-aws-ec2-external-inventory-script
    • Jenkins 建置範例(script),只要修改 yml 檔案名稱即可:
      • develop site
        • export ANSIBLE_HOST_KEY_CHECKING=False
          export EC2_INI_PATH=$WORKSPACE/dynamic-inventory-ec2.ini
          export AWS_ACCESS_KEY_ID=XXX
          export AWS_SECRET_ACCESS_KEY=OOO
          export DEPLOY_TARGET=site-develop.yml

          ansible-playbook $WORKSPACE/$DEPLOY_TARGET -i $WORKSPACE/bin/ec2.py --private-key=$HOME/.ssh/ansible-deploy.pem
      • alpha site
        • export ANSIBLE_HOST_KEY_CHECKING=False
          export EC2_INI_PATH=$WORKSPACE/dynamic-inventory-ec2.ini
          export AWS_ACCESS_KEY_ID=XXX
          export AWS_SECRET_ACCESS_KEY=OOO
          export DEPLOY_TARGET=site-alpha.yml

          ansible-playbook $WORKSPACE/$DEPLOY_TARGET -i $WORKSPACE/bin/ec2.py --private-key=$HOME/.ssh/ansible-deploy.pem
      • production site
        • export ANSIBLE_HOST_KEY_CHECKING=False
          export EC2_INI_PATH=$WORKSPACE/dynamic-inventory-ec2.ini
          export AWS_ACCESS_KEY_ID=XXX
          export AWS_SECRET_ACCESS_KEY=OOO
          export DEPLOY_TARGET=site-production.yml

          ansible-playbook $WORKSPACE/$DEPLOY_TARGET -i $WORKSPACE/bin/ec2.py --private-key=$HOME/.ssh/ansible-deploy.pem
  • Ansible 找尋最新 package files
  • Ansible 設置自動要求更新
    • $ ansible-galaxy install changyy.self-update 
    • https://github.com/changyy/ansible-role-self-update
    • 比較雜亂一點,原理:
      • 機器部署時,建立一個 auto update script (負責通報 deploy server 更新指定 host),將此 script 埋入開機執行區( /etc/rc.local )
        • 當機器啟動時執行該 script ,把部署此機器該有的資訊以 ssh remote command 丟給 deploy server 
      • 該 ssh remote command 包含的動作
        • 登入 deploy server 並切換至 ansible workspace
        • 透過 dynamic inventory 建立動態 host 資訊
        • 執行 ansble-playbook 批次指令
      • Deploy server workspace 範例:
        • $ cat bin/echo.sh
          #!/bin/bash
          echo "{\"$HOST\":$DATA}"

          $ HOST=MySite DATA=[\"SERVER_IP\"] bash bin/echo.sh
          {"MySite":["SERVER_IP"]}

          $ cd ansible-deploy-dir && \
          ANSIBLE_HOST_KEY_CHECKING=false \
          HOST=MySite \
          DATA=[\"SERVER_IP\"] \
          ansible-playbook MySite.yml \
          -i bin/echo.sh \
          --private-key=mysite-login-key.pem

2015年11月10日 星期二

[Linux] 架設 Jenkins 筆記,以 Git plugin 與 PHP CodeIgniter - command-line interface (CLI) 定期任務為例 @ Ubuntu 14.04

架設還滿簡單的,幾行指令搞定:

$ wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
$ sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
$ sudo apt-get update
$ sudo apt-get install jenkins
$ sudo service jenkins start


如此一來,預設在 http://localhost:8080 就可以瀏覽到。

接著安裝一些工具,之後會用到:

$ sudo apt-get install git

接著紀錄一下自己的操作設定:
  • 管理 Jenkins -> 設定全域安全性
    • 勾選 Disable remember me
    • 安全性領域
      • 使用 Jenkins 內建使用者資料庫
    • 授權
      • 矩陣型安全性
        • 關閉 匿名使用者 所有權限
  • 管理 Jenkins -> 管理外掛程式
    • 更新
      • 把所有項目更新
    • 可用的
      • 搜尋 GIT plugin 跟 GIT client plugin 並安裝(若系統沒有 git,安裝完可以在 Jenkins 組態裡看到一些錯誤訊息)
其中授權那塊,必須先建立使用者,可以先從"登入成功的使用者可以做任何事"開始設定,過程會導入到建立使用者的流程。若有設定錯誤的地方導致無法管理時,可以修改 /var/lib/jenkins/config.xml 將 <useSecurity>true</useSecurity> 改成 <useSecurity>false</useSecurity> 後,再重新啟動 jenkins (sudo service jenkins restart)即可解決。

如此一來,就建立好 Jenkins 環境,而新工作也能夠用 git 了!擬個範例試試:假設專案在 bitbucket 管理,並使用 PHP CodeIgniter 架構,定期透過此專案來執行分析任務

作法:
  • Jenkins -> 新增作業 -> 填寫作業名稱(StudyJenkinsRoutine) -> 建置 Free-Style 軟體專案
    • 原始碼管理
      • Git
        • Repository URL: git@bitbucket.org:group/project.git
        • Credentials -> Add -> SSH Username with private key -> Enter directly (搭配 Bitbucket SSH 存取即可)
        • Additional Behaviours -> Advanced sub-modules behaviors -> 勾選 Recursively update submodules
    • 建置觸發程序
      • 定期建置(每十五分鐘跑一次,語法跟 crontab 一樣,但會建議用 H/15 來使用)
        • */15 * * * *  
    • 建置
      • 執行 Shell
        • php $WORKSPACE/index.php controller/function
如此一來,透過 Jenkins 的 Web 介面就可以設定與執行一些功能了,唯一留意的是執行工作上是否擁有相關的環境資源,例如範例是執行 PHP Framework 做事,那就得確保 php5-cli 裝了沒,若做的事跟資料庫相關,又得確定 php5-mysql 裝了沒等等。此外,上頭執行的 Shell 有用到 Jenkins 環境變數,要留意有些資料是跟 Jenkins 建立的工作名稱是相關的,例如工作名稱若有空白、等號以及相關的特殊符號時,極有可能會影響 shell script 的執行的。

關於 Jenkins 相關的路徑安排都跟 jenkins 帳號相關,例如 Jenkins 家目錄在 /var/lib/jenkins ,而添加一個任務名為 StudyJenkinsRoutine 時,其 $WORKSPACE 會是 /var/lib/jenkins/jobs/StudyJenkinsRoutine/workspace 的,這個位置也是 git clone 的資料所在。

最後,如果 Jenkins 是架設在 AWS EC2 上,若可以搭配 ELB 跟 SSL 憑證時,可以偷懶使用 ELB 將 https 流量導向到 Jenkins 8080 ,可以無痛提供 https 服務囉。

2015年10月20日 星期二

透過 Bitbucket、Jenkins、Slack 打造持續發佈打屁等自動化架構

透過 Bitbucket 作為 git 版本控制的服務托管處,而 slack 則是工程師打屁好去處,而 Jenkins 則是打造一鍵發佈的便利介面。雖說連續動作也可以化簡成一隻 script,但能夠端出 Web UI 介面,還是大勝!

首先提一下 git 版本控制,透過 Bitbucket 服務,人多的話還是花一點小錢了!在 Bitbucket 可以建立群組概念,大概可粗略分成 Administrators、Developer、Deploy 三個個群組(若要細分則可以變成 iOS Developer、Android Developer、Web developer 或是甚至以專案為單位等),這邊設計讓所以有成員都進 Developer 並且 Developer group 預設對所有專案擁有 read only 權限。而埋了一個機器人在 deploy group 中,預設沒有任何權限(機器人不需進入 developer group)。當有專案要搭建自動發佈流程時,請專案擁有者或管理者,讓專案可供 Deploy Group 有 write 權限,這是為了 Jenkins 發佈新版時,能夠打個 tag 記錄狀態。而 Deploy group 裡的機器人,就只需添加個 ssh key 即可。

在 Jenkins Web UI:
  1. 建立作業 => 填寫作業名稱 => 建置 Free-Style 軟體專案 
  2. 設定 Slack Notifications => 進階設定 Team Domain、Integration Token 和 Project Channel => Test Connection
  3. 原始碼管理 => git => git@bitbucket.org:group/project.git => Credentials 搭配 Bitbucket SSH key => Branches to build 要指定 => Additional Behaviours => Advanced sub-modules behaviours => Recursively update submodules
  4. 建置環境 => Create a formatted version number => 設定 Environment Variable Name (VERSION) => Version Number Format String (1.0.0) 
  5. 建置 => 例如拉完程式碼後想要做的事,如 /path/project-build.sh project-name  $VERSION $BUILD_NUMBER $JOB_NAME 
  6. 建置後動作 => Git Publisher => Push Only If Build Succeeds => Tag to push (develop-$VERSION-$BUILD_NUMBER) => Target remote name (origin)
如此一來,開發者可以用 bitbucket 持續開發,並且用不同 branch 管理,如 develop branch、alpha branch、release branch 等,而 Jenkins 就建立三個任務,分別從上述 branch 取資料出來使用,而在 "建置" 跟 "建置後動作" 都可以對各個 branch 操作做細部的調整。

例如"建置"中的 /path/project-build.sh 的程式,就可以包含建立 RPM 、更新 repos 等行為,同時有環境變數 $VERSION $BUILD_NUMBER $JOB_NAME 拿來輔助。

以上就是將程式碼編譯打包的流程,若要再添加上 deploy 流程時,可以再額外建置一個 Jenkins 工作,裡頭只需填寫 slack 通知和建置項目,而建置項目就可以一隻 script 處理發佈的動作即可,而在相對應工作中,把剛剛的 deploy task 建立相依性即可。

如此一來,當 Jenkins 每一次建置時,各個階段的都丟訊息至 slack 指定的頻道,等同通知相關人員。若需要做類似 git hook 來達成自動建置時,可以使用 Jenkins "建置觸發程式" 裡的輪詢  SCM 項目,例如每 10 分鐘確認一次 bitbucket 專案狀況等,達成類似 git hook 行為。

2015年1月24日 星期六

[Linux] 快速安裝 Gitlab 及簡易設定 @ Ubuntu 14.04

感覺近年來幾套出色的管理套件都是 Ruby 派的,例如 Redmine 等,然而有許多安裝瑣事要處理 Orz 所幸 Gitlab 官方有打包一個 debian package 讓初學者可以快速上手:

$ wget https://downloads-packages.s3.amazonaws.com/ubuntu-14.04/gitlab_7.6.2-omnibus.5.3.0.ci.1-1_amd64.deb
$ sudo apt-get install openssh-server
$ sudo apt-get install postfix # Select 'Internet Site'
$ sudo dpkg -i gitlab_7.6.2-omnibus.5.3.0.ci.1-1_amd64.deb
$ sudo gitlab-ctl reconfigure


如此一來,預設 http://localhost/ 就可以登入查看了。然而,預設環境比較適合體驗啦,我又多做了幾個動作,包含也在系統裝上 Ruby2.0 方便未來的相關使用。

更新 Gitlab 環境:
$ sudo vim /etc/gitlab/gitlab.rb

# 對外 Web 資訊
external_url = 'http://YourPublicDomainName'
# 對外 SSH 資訊
gitlab_rails['gitlab_ssh_host'] = 'YourPublicDomainName'
# 時區
gitlab_rails['time_zone'] = 'Asia/Taipei'
# 開啟 https 服務, 以及強制使用 https
nginx['redirect_http_to_https'] = true
nginx['redirect_http_to_https_port'] = 80
nginx['ssl_certificate'] = "/etc/gitlab/ssl/YourPublicDomainName.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/YourPublicDomainName.key"

$ sudo gitlab-ctl reconfigure
$ sudo gitlab-ctl restart


更新 Postfix 環境:

$ sudo vim /etc/postfix/main.cf
myhostname = YourPublicDomainName
$ sudo postfix reload


安裝 Ruby 2.0 (非必要):

$ sudo apt-get update
$ sudo apt-get install ruby2.0 ruby2.0-dev
$ ruby -v
ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux]
$ gem -v
1.8.23
$ sudo ln -sf /usr/bin/ruby2.0 /usr/bin/ruby
$ sudo ln -sf /usr/bin/gem2.0 /usr/bin/gem
$ ruby -v
ruby 2.0.0p384 (2014-01-12) [x86_64-linux-gnu]
$ gem -v
2.0.14


以上則是稍微完整一點的調整。

然而,有時為了確保服務長久性,會有一些變動方式,例如 gitlab 資料儲存在於 /var/opt/gitlab ,可以給予一個獨立空間維護,因此,在安裝 gitlab 軟體前,先自行把 /var/opt/gitlab 擺在額外的 partition (此例是 AWS EC2 管理,給予一個 64GB 空間: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-using-volumes.html ):

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  20G  0 disk
└─xvda1 202:1    0  20G  0 part /
xvdb    202:16   0   4G  0 disk /mnt
xvdc    202:32   0  64G  0 disk
$ sudo mkfs -t ext4  /dev/xvdc
$ sudo mkdir /64GB
$ sudo mount /dev/xvdc /64GB
$ sudo mkdir -p /64GB/gitlab /var/opt
$ sudo ln -s /64GB/gitlab /var/opt/gitlab


接著再跑安裝 gitlab 流程...如果已經安裝了,那就是配置好 /64GB 後:

$ sudo gitlab-ctl stop
ok: down: logrotate: 1s, normally up
ok: down: nginx: 0s, normally up
ok: down: postgresql: 0s, normally up
ok: down: redis: 1s, normally up
ok: down: sidekiq: 0s, normally up
ok: down: unicorn: 0s, normally up
$ sudo cp -a /var/opt/gitlab /64GB/gitlab
$ sudo mv /var/opt/gitlab /var/opt/gitlab-bak
$ sudo ln -s /64GB/gitlab /var/opt/gitlab
$ sudo gitlab-ctl start

2014年5月29日 星期四

[Linux] 讓 git checkout/diff 略過 file permission 屬性

最近把 git 當作 deployment 過程的一環,接著就會碰到一個問題,有時因為需求要調整 file permission ,此時就會造成 git checkout 失敗,要求要先 merge 在行動。雖然 file permission 容易出現在 Windows / Linux ,但在 Linux 環境用 git 當作 deployment 時,也常有身份、權限的改變而造成一樣的影響。

解法:

$ git config core.fileMode false



$ git -c core.fileMode=false diff
$ git -c core.fileMode=false checkout