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

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

Dockerを本番投入した話

このまま忘れてしまうのも勿体無いので記録に残しておこうかなと。

blue1st.hateblo.jp

技術系のネタは最近は別ブログの方でやってたけど、具体的なコードなんかは無いので今回はこっちで。

blue1st-tech.hateblo.jp

思い出した・思いついたら随時追記していく予定。


概要

フィーチャーフォンの時代からのサービスで、 無茶な拡張や教育不足や委託によるアレな開発状況によって、 コードも環境も技術的負債が山盛りの状態だった。

幸いにしてサーバを移設する機会に恵まれたので、 状況を改善するべく検討を進めた。

解決したかった問題

様々な部分において、環境ごとの差異が看過できない状態になっていた。

サーバによってインストールされているランタイムやモジュールのバージョンが異なることもあれば、 パスが異なることをコードにベタに記述してバージョン管理しないことにより対処している部分があったり、 そもそも環境によって同名のスクリプトの内容が書き換えられていたり。

バージョン管理ももはや正しく機能していなくて、必要なファイルだけ明示的に本番環境に上げるような綱渡りな運用になっていた。

おそらくリアルタイムでは、「急いで対応しなきゃいけないから仕方ない、後でちゃんと揃えよう」とかなんとか考えていたのかもしれないが、 往々にしてそういう意識は長続きしないもの。

結果として、どのサーバ環境での挙動が「正」なのかも分からない状態となっていた。

こうなってくると新たに環境を構築するのも困難だし、 リリース前の検証作業も不確実なものとなってしまう。

Dockerの導入

もちろんそれぞれ個別には対処法はあるにはあるんだけど、 それを全て長期的に完全に徹底していくことは困難なように思えた。

個人的には「気をつければ」とか「ちゃんと確認すれば」とかいった前提で成り立っているような運用というのは即ち無用にリソースを消費している状態なので、 今問題ないからといって看過すべきではなくすぐにでも改善すべきだと思っている。

そういったストレスを抱えながら開発運用していくよりも、 Dockerを用いた「可搬性ある形」を前提として使い方を習得してもらうほうが現実的で長期的なメリットもあると考え導入に踏み切ることにした。

(とはいえ、僕が使いたかったから理由を揃えて押し切ったという側面はちょっとある。 退社時期的にちょっと申し訳ない気もしている。)


続きを読む

Consulに自動でDockerコンテナのサービスを登録する

ここのところすっかりマイ・フェイバリット・ツールなConsulとDockerの話題。

blue1st.hateblo.jp


別件を色々調べてたんだけど、なんだか便利なものを見つけたので。

Registrator

大雑把に言えば、ホスト上で起動しているコンテナの情報を読み取って、 うまい感じにConsulのAPIを通じてサービスを登録してくれるツール。

続きを読む

Consulを導入する

www.consul.io

DNS、サービス検知、KVS、イベント検知、Webフロントエンド・・・etc

Consulには単一バイナリながら様々な機能が含まれている。

多機能さゆえにConsulなるものが何であるかを一口で説明するのはなかなか骨が折れるのだが、 実際に手を動かしてそれらを使ってみると「系としての運用を効率化してくれるツール」としてそれらがまとめられていることが分かる。

サービス検知とそれに紐付いたDNS制御によりホストの増減に自動で対応するなんてことも考えられるし、 Consul-Templateと組み合わせてWebUIをさながらミドルウェアの集中管理画面として使用することも可能だ。

システムの中心に据えることで運用にまつわる諸々の面倒を無くしてくれる便利なツールなのだ。


Consulは本来は多数のサーバを運用するような場面で真価を発揮するツールではあるが、 単一サーバの運用においても役立つ要素はある。

単純にサービスの使用ポートと死活状態が一括で確認できるだけでもありがたいし、 先にも述べたミドルウェアの管理画面として活用するという面でも利用価値はあると思う。

(個人的には1コンテナ1機能主義に反するけど、Dockerのコンテナ内にConsulを収めて連携させるみたいな活用法もあるしね。)

そんなわけで自宅サーバ(Ubuntu 16.04)に導入してみた。

続きを読む

GitLab CIをDockerで導入してみた

業務じゃ運用っぽいことやってるくせにCI(継続的インテグレーション)まわりを全然カバーできてないのはそろそろ恥ずかしいので、 自宅サーバで色々動かして勉強してみようという試み。

(以前に軽くJenkinsはさわったことあるけど、スペックとかの問題でまともには運用できてなかったんだよな・・・)

今回導入してみたのはGitLab CI

会社でも自宅でもプライベートリポジトリとして利用しているGitLabなのだが、 都合が良いことに8系からはCI機能が統合されたらしい。

GitLabのCI機能を使うためにはあとはRunnerというビルド等を行う側を用意さえすればよいのだが、 こちらも幸いなことに本体同様にDockerイメージがある。

blue1st.hateblo.jp

そんなわけで、先日のGitLab本体に加えてGitLab CIもDockerで動かしてみることにした。

続きを読む

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

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

blue1st.hateblo.jp

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

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

続きを読む

ReadyNAS104にHDDを追加した

HDDが大容量化してきた昨今、 保存できるデータが増えて嬉しい反面、 一台の故障により受けるダメージもその分大きい。

いかに技術が進もうともHDDは物理的な回転部品を含む故障しやすいパーツなわけで、 消えたら泣いちゃうようなデータがある人間は、 ストレージの冗長化なりバックアップなりは検討しておくべきだったりする。

そんなわけで、今回クレジットカードのポイントが溜まって良い感じにアマゾンギフト券が手に入ったので、 半月前に導入したNASにHDDを追加してRaid1を構成してみた。

blue1st.hateblo.jp

「してみた」とはいってみたが、実際の手順は空いてるベイにHDDを突っ込んで待つだけ。

X-Raid機能が勝手にセッティングしてくれる。

続きを読む

ReadyNAS104導入してみた

f:id:blue1st:20160124015044j:plain

ネットワーク上のメディアを再生できるデジタル機器が身近に増えてきた昨今、 バックアップ用途やメディアサーバとして一家に一台NASがあると何かと便利だったりする。

かくいうウチでもこれまではN54LにsambaやらMediatombやらを入れたりしてNASとしても活用してきた。

blue1st.hateblo.jp

blue1st.hateblo.jp

だが、実験サーバとしての役割とNASという実用の役割とを共存させることに限界を感じてきたこともあり、 今回思い切ってNAS専用機を導入してみることにした。

専用機を購入するにあたっては冗長性を鑑みて最低限2ベイ以上のものをと考えていたのだが、 値段や評判、拡張性などを考慮してNetgearのReadyNAS104を購入。

4ベイのものとしては低価格とはいえ、それでも小さくはない出費。

だがそこは上手くできたもので、後述するがReadyNASなら随時HDDを追加していくという運用ができる。

そんなわけで、今回は本体とHDDを一つ買ってRAID無しで運用を開始し、 以降余裕があるときにHDDを買い足していく方針とした。

続きを読む