gitをGitLabに移行したよ

SE

「GUIなんかいらんわ」って思って私的リポジトリをずっとさくらVPSに入れたgitoliteで運用してたけど、業務ではGitLabずっと使ってるしいろいろ進化してインストールも楽になってるようだから最新版入れてみようかなということで入れてみた。


進化が激しくて巷のブログに「こうやってここを変更する」とか書いてあるのはほとんど陳腐化していて、結局公式ドキュメントに書いてあることを愚直に実行していくのが吉らしい。
ここにも流れを記すけれど、同様にすぐに陳腐化すると思われるので実際にインストールする際にはその時点での公式ドキュメントみるよろし。インストールコマンド実行後にどこを参照しなさいとかどこを変更しなさいとか教えてくれるのでちゃんとコマンド実行後の出力をみてれば大体わかるはず。

今回の条件

  • CentOS6。
  • 既存のgitリポジトリあり（gitoliteベースだが実質的には素のgitと同じ）。
  • 既に別件でnginxを載せているホストに相乗りさせる。ただしGitLabの独立したnginxを使う。
  • 定期バックアップもする。

注記

  • nginxやpostgresqlなどのミドルウェアは「/opt/gitlab」や「/var/opt/gitlab」に入るのでファイル的には既に入っているものと競合しない。
  • 既存のものと競合するのは基本的にはポートのみ。
  • gitユーザはホームディレクトリが「/var/opt/gitlab」に変更される（GitLabで登録したデプロイキーなどはこの中の.ssh配下で扱われる）。既にgitユーザが存在する場合は「/home/git」の中身自体はそのまま残る。

資料

今回はCentOS6上にいれるので以下がベース。
https://about.gitlab.com/downloads/#centos6

HTTPSで使うので以下も参照。
https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/nginx.md

既存のgitを移行する際には以下を参照。
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/raketasks/import.md

バックアップのやり方は以下。
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/raketasks/backup_restore.md

流れ

「/etc/sysconfig/iptables」を更新してポート「12345」をGitLabのWeb UI用に開けて「sudo service iptables restart」する。


公式ドキュメントに沿って以下を実行。ただしドキュメントには「sudo lokkit -s http -s ssh」とあるがiptablesは自分でいじりたかったので実行せず（ほとんどデフォルトで既に入っていたり設定されてたりするが、再度適用しても困るものではないので気にせず実行）。

sudo yum install curl openssh-server postfix cronie
sudo service postfix start
sudo chkconfig postfix on


公式ドキュメントに沿って以下を実行。

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash
sudo yum install gitlab-ce


「sudo view /etc/gitlab/gitlab.rb」設定ファイルを開く。巷のサイトではymlを更新してたりするが現バージョンではreconfigureするときに使われるのはこちらのファイル。別のファイルをいじっても上書きされる可能性があるので注意。
自分の場合は以下を変えた。たぶんコメントアウトされてるのはデフォルト値なので同じ値ならわざわざコメントアウトを外さなくてよさそう。

※SSL使う場合でもSSL用の設定は不要（後述の通りキーペアを所定のルールで置けば勝手に適用してくれる）。Web UIのポート設定も上記のようにexternal_urlに混ぜておくだけでOK。「○○port」などの設定はいじらなくてよい。


以下のようにオレオレSSL証明書を生成。公開鍵は自分の作業PCの「信頼されたルート証明書」に登録。

sudo mkdir -p /etc/gitlab/ssl
sudo chmod 700 /etc/gitlab/ssl

openssl req -nodes -newkey rsa:4098 -keyout foo.bar.com.key -out foo.bar.com.csr -subj "/C=JP/ST=Tokyo/L=Shinjuku-ku/O=FooBar/OU=IT Department/CN=foo.bar.com"
openssl x509 -req -days 3650 -sha256 -in foo.bar.com.csr -signkey foo.bar.com.key -out foo.bar.com.crt

sudo cp foo.bar.com.key foo.bar.com.crt /etc/gitlab/ssl

※ポイントは「/etc/gitlab/ssl」に「【external_urlで設定したホスト名】.key」「【external_urlで設定したホスト名】.crt」というファイル名で格納すること。こうすると設定ファイルに明示しなくても自動的に読み込んでくれるようになる。


これまでの設定後に「sudo gitlab-ctl reconfigure」とするとchefで諸々導入された末にGitLabが起動する。
作業PCから「https://foo.bar.com:12345」にアクセスして初期パスワードでログインするとパスワードの変更を求められるので適宜変更しておく。


バックアップはroot権限で動くcronに以下を記すと2時に発動して「/var/opt/gitlab/backups」にはき出される。
ここではき出されたバックアップファイルは「/etc/gitlab/gitlab.rb」の「gitlab_rails['backup_keep_time']」に記した期間（秒）が過ぎると次のバックアップ処理時に削除される。

0 2 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1

AWSで新規にシステムを構築する際のアドレス体系案

SE


AWSのネットワーク設計をサボらないでちゃんとやる
という記事があって、自分もちょうどこのあたりを検討しているので自分の検討している体系も書いてみる。


この体系は「現時点でオンプレミスの環境があってそことVPN接続する」「今回たまたまAWSを使っているものの今後ほかのクラウド環境も使うかもしれない」「少し共通の機構を持つ小さいシステムが10〜20個ぐらい格納されるかもしれない」という前提で作ってある。


おそらく方向性としては「システム別に独立した体系にする」などの方針でシステム別に小分けになって相互に疎結合の通信のみにするというのもありえるが、今回はオンプレミスからの緩やかな移行なども鑑みて「大きな体系内に小さなシステムを内包する」方向性にしている。


ビット体系：AAAAAAAA BBBBBCCD DDEEFFGG GGGGGGGG

CIDR bit 個数 概要 説明
A /8 8 - クラスA クラスAのプライベートアドレス体系（＝10）。
B /13 5 32 事業 Aとセットで当該事業に割り当てられた値。
C /15 2 4 拠点 AWSの各リージョンや別クラウド。DRも独立拠点。
D /18 3 8 環境 共通、本番、ステージング、開発、DRなどの環境。VPCはこの単位。
E /20 2 4 カテゴリ Private、Publicなどのカテゴリ。当面はこの2で残り2つは予備。
F /22 2 4 AZ アベイラビリティゾーン。ここまででサブネットを形成。4AZまで対応しているが事業によっては2AZにして他のセグメントを拡張してもよい。
G /32 10 1024 ホスト ホストやELB等の資源。
  • AWSのVPCの制限としてCIDRは/16〜/24なのでA〜Dで1VPCの基底CIDRとする。
  • 環境は「共通」とそれ以外は性質が異なり、「共通」以外の各環境は「共通」とVPC peeringで接続する。
  • 「共通」以外の各環境は相互に直接通信できない。
  • VPNとの接続はPrivateカテゴリのみ許可する（各環境のPrivateカテゴリにVPNが張られる）。
  • 外部ELB/踏み台/NATはPublicカテゴリに入れる。
  • DBサブネットグループやElasticCacheサブネットグループはA〜Fまでで決まるサブネットを設定する。あまりサブネットを小分けにしすぎない。
  • 何らかの事情で自動で勝手に消費されない固定IPアドレス帯が欲しい場合はEのカテゴリを1つ固定IP用として利用する。
  • 非AWSの場合、D以降は異なる体系になる可能性が高い。


事業によってはホスト部分（G）は1桁減らして512にしてそれ以外のところを拡張してもよいかもしれない。


この体系を検討するうえで参考にしたのは以下。
図が2あってとても参考になるのだけれど微妙に間違いがあるので注意。
https://www.itcloudarchitect.com/index.php?view=posts&id=169

AWSでオートスケーリングする際のインスタンス自己構成の実現方式案

SE AWS

オートスケールする際に各インスタンスをどうやって構成するのがよいかなっていうのを考えたのでメモ。

まず、起動速度が求められるケースではAMIを自分で作るというのがあるのだけれど、AMI作るのに時間が掛かるし、AMI管理するのも面倒だし、大元のAMIのアップデートも気にしないといけないしというのがあるので、AMIはAWSが提供するありのままのAmazonLinuxをいじらずに使いたい。もしいじらないといけないならPacker＋Ansibleでたぶん頑張るけど。

で、やはり個人的には（起動速度がそれほど求められないケースでは）各インスタンスが起動時に自己構成するBootstrap Patternがよいんじゃないかなと。

で、考えたのが以下のような流れ。
利用プロダクトとしては「ansible」「S3」「git（gitlab）」。

  • EC2インスタンスの役割を決める。
  • 役割別にIAMロールを作る。
  • S3にIAMロール別に参照権限を分けた秘密鍵置き場を作る。
  • 秘密鍵置き場にgitの秘密鍵を置く。
  • 秘密鍵置き場にansible-vaultの秘密鍵を置く（playbookに機密情報がないなら不要）。
  • gitに役割別のplaybookを置く（プロジェクトやパス名に役割名を入れるなどして分離）。
  • EC2のオートスケールを構成する際に役割を示すタグとIAMロールを付与する。
  • EC2のオートスケールを構成する際に以下の処理をUserDataに入れる。
    • pip install ansible （yumのepelでも入るがその後うまくいかないみたい）
    • S3から秘密鍵を取得して自身のよきところに格納する（~/.ssh/confの設定とかも）。
    • gitの秘密鍵を使ってgitからplaybookを取得する。
    • ansible-playbookを実行する（ansible-vaultを使ってる場合は引数に「--vault-password-file」指定）。

playbookに機密情報がなければansible-vaultの秘密鍵は不要。
gitの秘密鍵も場合によっては不要なので本当にシンプルな構成ならS3自体不要。
playbookの構成管理しないぜというケースでは逆にgitをなくしてS3にplaybookを置くでも可。

この機構のミソは「機密情報にアクセスするための秘密鍵自体をどう守るか」という芋づる式に現れる機密情報の連鎖のなかで「インスタンスに付与されたIAMロールとそれに基づくS3の参照権限」が最終的にそれらの秘密を担保するところ。