そんな今日この頃でして、、、

コード書いたり映画みたり。努力は苦手だから「楽しいこと」を探していきたい。

自宅サーバのOSを入れ替えた

自宅サーバとしてN54Lを購入してからおよそ三年。

blue1st.hateblo.jp

セットアップした当時とは色々と状況が変わったこともあり、 これまでCentOS6系で運用していたものをUbuntu15系にしてみた。

そんなわけで色々メモ的なやつをば。


OSの選定

さて、今回OSを入れ替えようと思った最大の要因がDocker運用。

以前にも書いたように、Dockerは既存の環境を汚さずに新しいミドルウェアやツールなんかを動かすことができて、 僕のようなサーバ自体にはそれほど明るくないアプリケーションエンジニアが新しいものを手軽に試すのには非常に有効な、 個人的にはここ数年で一番のパラダイムシフトだったりする。

blue1st.hateblo.jp

プライベートはもとより仕事でも使う機会が出てきた。

だが、ver1.8以降ではRHEL/CentOS6系はサポートから外されることになってしまった。

それでも動かせることは動かせるのだが、 カーネルのバグで/lib/docker以下がモリモリ肥大化していってしまう問題は実運用していくと辛い。

一度リモートリポジトリに上げて各種ファイルを消して戻す、 みたいな小手先の対応もできなくはないが、 長期運用してくことを考えると面倒くさすぎる。

blue1st.hateblo.jp


一度ツールを使ったCentOS6→7のアプグレをしようともしてみたのだが、 各所でもやめといた方が良いと言われていた通り、やっぱり上手くはいかなかった。

再起動後のフェーズでどうしても止まってしまうのだ。

そんなわけでOSを新規に入れなおそうということになり、 職場でも使ってるCentOS7かDockerも推奨してるUbuntuかで迷ったわけだが、 昨今Ubuntu推奨のプロダクトをよく見る印象もあって思い切って乗り換えてみた。

CentOS vs Ubuntuみたいな話題でググると宗教戦争じみた感じの記事ばっかり引っかかるけど、 今時どっちのOSじゃなきゃ困るみたいなことも無いしね。



OSインスト-ルとかはインストーラーもモダンになり特に書くほどのこともない。

あとはやったことメモ。

Docker

apt-getで入るDockerは古いらしいので公式Docに従ってインストール。

docs.docker.com

GPGキーの箇所でエラーが出て戸惑ったが、 何回か繰り返したら普通に通った。

Docker Compose

こっちも公式Doc通りの手順で。

docs.docker.com

Gitlab移設

旧環境の役割の一つがGitlab運用。

前はomnibus-gitlabをrpmでちゃちゃっとインストールしたのだが、 今回はGitlab自体もDockerで運用することにした。

幸いなことに新しめなGitlabにはダンプ・リストアの手段が用意されているので、 これを用いることにした。

ダンプ

omnibus-gitlabでインストールした場合ならば、 /opt/gitlab/以下に諸々のファイルがある。

/opt/gitlab/bin/gitlab-rake gitlab:backup:create RAILS_ENV=productionを実行することで、 /var/opt/gitlab/backups以下にtarファイルが生成される。

Dockerイメージの選定

gitlabが入ったイメージはいくつかあるのだが、 後述するバージョンの問題もあってsameersbn/gitlabを使った。

github.com

githubの方で記述されているものをベースとしつつ、 タイムゾーンやポートやドメインなんかを書き換えてdocker-compose.ymlを生成。

順序的に前後してしまうが、イメージとしては現時点での最新8.4.4のものが用意されているが、 これをそのまま使うと旧環境8.3.2のダンプファイルをリストアすることができなかった。

ということで一旦8.3.2のイメージを使う形に書きなおした。

一旦起動した後に古いバージョンに戻す際には一時ファイル(デフォルトでは/srv/docker/gitlab以下)を消そう。

リストア

普通にdocker-composeで起動すると初回に環境構築をしてくれる。

一通り立ち上がったことを記述したことを確認した上で作業開始。

まずは先のダンプファイルをbackupsディレクトリ(デフォは/srv/docker/gitlab/gitlab/backups/)に移す。

次にgitlab本体が動いているコンテナをpsコマンドで確認し、 docker exec -it [コンテナID] bashでコンテナ内に入り/sbin/entrypoint.sh app:rake gitlab:backup:restoreでリストア実行。

上手くいくと、どのバックアップファイルを使うかの選択が出るので、 先ほど収めたファイル名を入力することでリストアを進めることができる。

ちなみにこの作業を行った後にdocker-compose.ymlのgitlabバージョンを8.4.4に書き換えることにより、 バージョンアップを正常に行うことができた。

CasperJSを使ったスクリプトもDocker化

自宅サーバではcronでスクリプトなんかも動かしていたのだが、 これらもDocker化しようと試みてみた。

blue1st.hateblo.jp

CasperJSが動くイメージもいくつかあるのだが、 最初に目についたvidiben/casperjsを使ってみることにした。

どうやらコンテナのホームディレクトリにscript.jsという名称で動かしたいスクリプトを納めれば良いらしい。

そんなわけで専用のディレクトリを作成を作成してそこにスクリプトをリネームして納め、 それをマウントする形で実行するようにした。

docker run --rm -it -v [スクリプトのあるディレクトリのパス]:/home/casperjs vidiben/casperjs


元々ツール系は結構Dockerで動かしていたものが多かったこともあり、 割と楽に移設することができた。

今回やっていてい参考になったところだと、 Dockerでマウントするデータディレクトリを一定の規約に従って作っておくことで、 今後移設や初期化の機会があった時に楽になるなということが教訓になった。

(/srv/docker/[用途]/[サービス]。例えば/srv/docker/gitlab/redisみたいな。)


今週末では触れられなかったが、職場で触ってみて好感触だったConsulなんかも入れたら色々捗るかもしれない。

多数のホストがある環境向けのツールではあるが、 単純に稼働しているサービスの状況(とポート)がひと目で分かるのは助かるし、 KVSとConsul Templateを組み合わせたミドルウェアの設定管理は単一ホストでも便利そうだ。

www.consul.io

Introducing Consul Template - HashiCorp

そんな感じで、今週はここまで。

プログラマのためのDocker教科書 インフラの基礎知識&コードによる環境構築の自動化

プログラマのためのDocker教科書 インフラの基礎知識&コードによる環境構築の自動化

DevOpsを支えるHashiCorpツール大全 Think IT Books

DevOpsを支えるHashiCorpツール大全 Think IT Books