mojavy.com http://mojavy.com/blog Tue, 11 Mar 2014 02:08:20 GMT Blogofile hourly 1 gitlab 6.6.4 CE のゆるふわセットアップ http://mojavy.com/blog/2014/03/11/latest-gitlab-setup/ Tue, 11 Mar 2014 02:08:20 JST <![CDATA[chef]]> <![CDATA[git]]> <![CDATA[tips]]> <![CDATA[gitlab]]> http://mojavy.com/blog/2014/03/11/latest-gitlab-setup/ gitlab 6.6.4 CE のゆるふわセットアップ <![CDATA[

gitlabもCentOSとUbuntuにはパッケージが提供されるようになったので、大分インストールが簡単になりました。

とはいえ、このパッケージはgitlab専用のマシンにインストールすることを前提にしているのか、小規模プロジェクトのために軽く使いたいよう場合ではつらいデフォルト設定となっています。安いvpsとかだと確実にメモリ不足でまともに動きません。

以下はとりあえずプライベートgitリポジトリが欲しいだけのような人のためのgitlabの設定の紹介です。

準備

https://www.gitlab.com/downloads/

ここからgitlabのパッケージをダウンロードします。 omnibus-ruby でつくられた全部入りパッケージなのでインストールでのコンフリクトは発生しないはずですが、既に稼動中のサービス(apache等)のことはあまり考慮されてないので使用するポートについては個別対応が必要です。

特に以下は注意が必要です。

  • nginx
  • redis
  • postgresql

ここでは、apacheが稼動しているubuntuにインストールします。

インストール

普通にインストールします。

$ sudo dpkg -i gitlab_6.6.4-omnibus-1.ubuntu.12.04_amd64.deb 
$ sudo gitlab-ctl reconfigure

ちなみにgitユーザが既に存在しているとこけるので消しておきます

$ sudo userdel -r git

gitlabの設定

gitlabの設定は /etc/gitlab/gitlab.rb に設定をかいて、chefで設定します。

$ cat /etc/gitlab/gitlab.rb
external_url "http://gitlab.example.com:8081"
unicorn["worker_processes"] = 1
postgresql["shared_buffers"] = "128MB"
postgresql["effective_cache_size"] = "32MB"

とりあえずpostgresqlがメモリを大量に食うので適当に減らします。

unicornもメモリ食いがちなので1プロセスにします。

external_urlにポートも含めたURLをかきます。apacheが80番で起動してるとnginxが起動できないので適当にはずします。ちなみに8080はデフォルトだとgitlabのunicornがつかっています。

このあたりは環境に応じて適当に設定してください。

gitlab-ctl reconfigure すると設定が反映されます。

その他の設定できる項目は /opt/gitlab/embedded/cookbooks/gitlab 以下のcookbookをみるといいです。

webサーバの設定

80番で起動しているapacheがいる場合はnginxにproxyします。

<VirtualHost *:80>
  ServerName gitlab.example.com

  DocumentRoot /opt/gitlab/embedded/service/gitlab-rails/public

  CustomLog  /var/log/apache2/gitlab_access.log combined
  ErrorLog   /var/log/apache2/gitlab_error.log

  ErrorDocument 502 /502.html

  <Directory "/opt/gitlab/embedded/service/gitlab-rails/public">
    Options FollowSymLinks
  </Directory>

  <Proxy *>
    AddDefaultCharset off
    Order deny,allow
    Allow from all
  </Proxy>

  ProxyVia On
  ProxyPreserveHost On

  ProxyRequests Off
  ProxyPass /assets/ !
  ProxyPass /uploads/      !

  ProxyPass / http://localhost:8081/ retry=1
  ProxyPassReverse / http://localhost:8081/

</VirtualHost>

以上ができたらapache再起動して、 http://gitlab.example.com にアクセスしてみてうまく表示できれば完了です。

]]>
chefを使うのを我慢したほうがいいとき http://mojavy.com/blog/2014/03/07/dont-use-chef/ Fri, 07 Mar 2014 00:09:26 JST <![CDATA[chef]]> http://mojavy.com/blog/2014/03/07/dont-use-chef/ chefを使うのを我慢したほうがいいとき <![CDATA[

chefを使いはじめるとあらゆるもののセットアップをchefレシピ書かずにやるのが気持ち悪くなってしまうけど、chefでやらないほうがいいものって結構あると思う。

  • redmine
  • gitlab
  • 小規模なシステムのzabbixのマスター
  • etc...

この手のものは、実際に使いはじめると多少は手作業での運用が必要になるので、誰かがつくったcookbookでいれてしまうよりかは手作業でいれてある程度どこになにがあるか把握しておいたほうがやりやすい。

自前でレシピ書いてもいいけど、当面は1台あれば十分なのであれば単なる二度手間でしかないのでセットアップ手順をメモに残す程度で十分。1

ある程度運用経験があってとりあえずすぐに動く環境を作りたい、という場合のみ出来合いのcookbookをそのまま使えばいいと思う。

などということを、1ヶ月くらいかけていろいろcookbook書いたあげく心が折れたときに感じた。


  1. まめにredmineみたいなものをアップデートしたいような人もたぶんあんまりいない 

]]>
debianパッケージをchefで削除する場合はpurgeを使う方がよい http://mojavy.com/blog/2013/09/10/chef-purge-package/ Tue, 10 Sep 2013 19:39:49 JST <![CDATA[chef]]> <![CDATA[ruby]]> <![CDATA[debian]]> http://mojavy.com/blog/2013/09/10/chef-purge-package/ debianパッケージをchefで削除する場合はpurgeを使う方がよい <![CDATA[

apt-getコマンドにはパッケージを削除するためのコマンドが2種類ある

  • remove: パッケージを削除するが設定ファイルはそのまま残す
  • purge: パッケージを削除するとき設定ファイルも削除する

chefをつかっているということは設定ファイルもchefで管理しているはずなので、設定ファイルを残す必要はない。 さらに、依存で入ったパッケージも一緒に削除されるように、options "--auto-remove"などとしてやるとよい。

ゴミは混乱の元なので早めに消すべし。

]]>
chef soloでAuthenticationFailedといわれたときの対応 http://mojavy.com/blog/2013/09/09/chef-solo-ssh-config/ Mon, 09 Sep 2013 20:43:04 JST <![CDATA[chef]]> <![CDATA[ruby]]> http://mojavy.com/blog/2013/09/09/chef-solo-ssh-config/ chef soloでAuthenticationFailedといわれたときの対応 <![CDATA[

公開鍵認証なホストに対してパスフレーズ入力無しでsshログインができるにもかかわらず、

$ knife solo cook myhost
Running Chef on myhost...
Checking Chef version...
Enter the password for username@myhost:
ERROR: Net::SSH::AuthenticationFailed: username

のようにいわれてchef soloの実行に失敗してしまうときがある。

パスフレーズ入力無しでsshできたということは、普通は以下のうちの少くとも1つは満たされている。

  1. ssh-agentに対象の秘密鍵が登録されている
  2. デフォルトパス($HOME/.ssh/id_rsa とか)に対象のパスフレーズ無し秘密鍵が保存されている
  3. ssh_configでパスフレーズ無し秘密鍵を指定している

それなのにAuthenticationFailed失敗してしまうのは、Net:SSHがデフォルトでは公開鍵認証を試行しない場合があるため。 1 これを回避するには、ssh_configでPubkeyAuthentication yesを明示すればよい。

なお、Net::SSHがどのような動きをしているかは以下のスニペットを試すとよい。

require 'net/ssh'
Net::SSH.start("myhost", "username", :verbose => :debug) {|x| p x }

備考

使ったのは以下のバージョン

  • chef: 11.6.0
  • knife-solo: 0.3.0

  1. この挙動はknife soloコマンドに-iオプションを渡しても変わらなかった。 

]]>