データパイプラインの基盤移行・統合と運用ルール整備を実施。可視化やリカバリ設計により、安定したデータ運用環境を構築しました。
最新のデータオーケストレーション技術を活用し、保守・運用の効率化と品質向上を実現しました。

技術要素

• Python
• dagster
• dbt
• Hadoop
• Athena
• Glue
• Docker
• PostgreSQL

プロジェクトの特徴

• データパイプラインの可視化
  dagster基盤による運用状況の見える化
• リカバリ設計
  途中からの復旧が可能な柔軟な設計
• 保守・運用ルール整備
  安定運用のための手順・ルールを策定

成果

• データ運用の安定化
• 保守・運用効率の向上
• 最新技術への対応
• 運用品質の向上

Altus-Fiveの強み

最新技術への対応力と運用ルール策定力で、複雑なデータ基盤の移行・運用も安定してリード。顧客の業務効率化と品質向上に貢献できる点が弊社の強みです。

The post 06 データパイプラインの開発・保守/運用 first appeared on 株式会社Altus-Five.

弊社は、この小さい開発会社なので、自社プロダクトを開発する分には、無償で使えるのだけど、受託開発で、依頼元の企業が大企業の場合、どうしたらよいのか、WEBで検索して調べたのだが、よくわからなかった。

仮に、開発会社がライセンスを持っていれば良いとして、納品したあとの保守を依頼元企業の保守チームが行う場合には、ライセンスが発生するので、予め Docker を開発に使うことに合意しておく必要はありそうだ。

WSL の Ubuntu でのみ Dcoker を使う

でも、有償なのは、 Docker Desktop であって、Docker Engine は無償で使ってよいので、 Docker Desktop を使わないで、 Docker を使う方法を調査した。

答えは簡単で、 Windows では、WSL の Ubuntu に apt コマンド等で docekr をインストールしたらよい、それだけだった。

Docker Desktop を使わないことのマイナス面は、なんだろうか？

• Dockerを操作する GUI が使えない
  「Use the WSL 2 based engine」で有効化される機能が使えない。
  これは、未調査なので、私の想像だけど、Windows と WSL とのメモリの共有はできないのではないかと想像する。
  他にも、ホストOSの Windows と連携して動く便利なものが動かないのだろう。
• PowerShell や GitBash 等から docker コマンドを使えない
• VSCode の devcontainer で使うときにひと手間かかる

VSCode の devcontainer の使い方

devcontainer が使えないわけではない。

WSL 側にも VSCode を入れてあるとしても、あれは vscode-server という headless のサーバー機能なので、Windows 側の VSCode が必要である。

そして、 VSCode が devcontainer を開始するときに、docker コマンドを使うようで、このコマンドを実行するのは、Windows 上からなので、Docker Desktop を入れてないと、エラーになる。

Docker Desktop が無い状態での devcontainer の使い方は、WSL側で、docker-compose 等を起動しておいて、 VSCode からは、そのコンテナにアタッチする形で、今までとほぼ同じように使える。

そして、 devcontainer cli というものが GitHub で公開されていて、これを使うと、以下のコマンドで、devcontainer を起動してくれる。

devcontainer up --workspace-folder .

devcontainer の設定は、 .devcontainer/devcontainer.json などで、設定しておくけど、これを読み込んで、コンテナを起動をしてくれる cli ツールである。

docker-compose で起動すると、 devcontainer.json に記載された extension が起動時にインストールされないので、この cli も使った方がよいだろう。

Docker Desktop の代替

ということで、Windows でも使い方を間違わなければ Docker は使って問題ない。

ちょっと、残念なのは、WindowsとWSLとのメモリの共有がされないので、WSLのディストリビューションに対してのメモリを、手動で割り当てておく必要がある。

あと、Docker Desktop の代替として、Podman というものがあるのだけど、これも少し使ってみたが、非常に荒っぽい言い方をすると、 上記のやり方を知っていれば、使う必要はなさそうだった。あまりメリットを感じなかった。

Podmanのインストール手順に従って、インストールを進めていくと、まずは、Podman Desktop（Docker Desktopのようなもの）が インストールされて、さらに GUI から、数ステップの操作を進めていくと、WSL に podman のディストリビューションの linux がインストールされて、 その linux の中に、Docker Engine 等の Docker 関連の OSS がインストールされて、コンテナの状態が操作できるようになる。

ただ、まだ枯れてない。
私が持っているプロジェクトの1つが、build できなかった。（buildが終わらない）
これがちょっと痛い！

Windows との連携機能が厚いわけでもなく、単なるダッシュボードみたいなもので、旨味が薄いので、 いまのところ Podman は使わなくてよいという判断である。 ホストOSとのメモリの共有ができるくらいの機能実装が出来るようになったら、再度、試してみることにしよう。

※ もしも、使い方が悪くて、動かないだけだったら、すみません。

最後に

いままで、合意のないまま Docker Desktop を使っていた人は、いったん、アンインストールして、上記のとおり、 linux 内でのみ docker を使うようにしましょう。

The post 開発会社が Docker のライセンスに準じて正しく使うために first appeared on 株式会社Altus-Five.

今のところ、使ってみた！というだけの記事なのですが、いくつか、気になったところを、書いてみようと思います。

WSL2 と Windows 間のファイル共有

WSL2 は Hyper-V の VM として動いていて、ファイルの共有は、相互にマウントすることで行われてます。

Windows のファイルシステムは、WSL2では /mnt/c に C ドライブがマウントされ、 WSL2のlinux（例 Ubuntu 20.04）のファイルシステムをエクスプローラーから参照するには、\\wsl$\Ubuntu-20.04 です。
ネットワークのファイルシステムのような仕組みになってるんでしょうね。
実際に、WSL2 の terminal で、Windows のファイルシステムのマウント先（/mnt/c 配下）に移動して、そこで docker を実行すると、若干、遅いような気がします。

WSL2で開発の仕事をするんだとしたら、linuxのファイルシステム上で、開発した方がいいです。
vscode にも Remote WSL というのがあって、↑の使い方が、すでに当たり前のようです。

ディレクトリの mv は実際にはコピー

WSL2 を入れて、既存の開発環境を linux 側に移動させようと思って、面倒なので、複数のプロジェクトを mv で一気に移動させようとしたのだけど、エラーになってしまいました。
何が起こったのかと思ったら、Cドライブの空き容量が無くなっているという・・・。
WSL2 <-> Windows間での mv はディレクトリ丸ごとのコピーを行ってるようです。移動元と同じサイズの空き容量がないと、失敗してしまうので、気を付けましょう。

動的メモリ割り当て

Docker Desktop は WSL2 で導入された動的メモリ割り当て機能が活用できます。
WSL2 で Docker を実行するとき、CPU とメモリは、必要量しか使われないため、あらかじめ Docker が使えるメモリ量の設定をしなくてもよいので、より効率的になります。

ただし、↑の状況が、好ましくないときもあります。
私の場合は、Windows 側で Eclipse を動かすときに、問題になりました。
WSL2側で、いろんなDockerコンテナを起動していて、メモリが消費されている状態で、 Eclipse を使うと、なんかモッサリとして、しばらく使い続けてると Eclipse が反応しなくなりました。

WSL2 側でメモリが食われ過ぎて、Windows側のメモリが無くてアプリが重たくなってしまったということだと思います。

Windows 側でも、メモリ食いのアプリケーションを動かすときには、WSL2 側でのメモリ使用量を制限した方がよいです。

WSL2 で最大確保できるメモリサイズは、デフォルトで PC 搭載メモリの 80% になっているようです。
このメモリ割り当ての最大値を小さく設定してみてください。 以下の記事に、そのやり方があります。
https://qiita.com/yoichiwo7/items/e3e13b6fe2f32c4c6120

Docker Desktop WSL 2 バックエンド を使っていくなかで、気になったこと、書き加えていこうと思います。

The post Docker Desktop WSL 2 バックエンドの使い始め first appeared on 株式会社Altus-Five.

Jupyter Notebookって？

WEBで検索すると「機械学習の現場で重宝する多機能Webエディタ」とタイトルされた記事が出てきます。
pythonでできていて、Jupyter Notebook自身が、httpサーバーの機能があり、http://localhost:8888/ でブラウザでノートを編集するんですが、編集している対象は、localhost上のファイルになってます。

ノートに書いたpython等のコード片を、ブラウザ上から実行すると、httpサーバーがそのコードを実行して、結果をノートにフィードするという感じになってます。たぶん。
コード片だけじゃなくて、もちろん、メモ書きもマークダウンで自由に書き込めます。
そして、実行結果がグラフとしてノートに記録することができて、そういうのを、画面を切り替えずに、1画面の中でできるというのが良いんだそうです。
ここに動画のわかりやすい説明があるので見てみてください。きっと使いたくなります。
http://techlife.cookpad.com/entry/write-once-share-anywhare

コードを書いて、実行して、その結果をグラフ表示したり分析してメモを添えたり、そういった ”一連の作業をノートとして書きとめる” ために、作られたんでしょうね。 確かに、そういうのが、欲しかった！
以前、話題になったニュースで、研究者は実験過程をすべてノートに記録するということを知りましたが、同じように、機械学習の試行錯誤の過程もノートに記録するわけなんだけど、Jupyter Notebookを使うと効率的ですよ・・・というわけですね。

機械学習以外で使ってみる

そして、今では、pythonだけじゃなくて、40種類以上のプログラム言語に対応していて、Spark、R、SQL、shell なんてのも使えるらしいです。

ということは、用途は、機械学習にとどまりませんね。ちょっと、思いつきで上げてみますね。

ターミナルのログ

teratermなどのターミナルのログ保存の代わりになりそうです。
コマンドとその実行結果と、それにメモ書きを添えて、きれいにノート保存できるので、気持ちが良さそうです。

コマンド起動用のショートカット集として

nodejsのgulpとか、laravelのartisanの実行とか、いつものコマンドなんだけど、ディレクトリ移動したり、コマンドのオプションなんだっけ？とか、そんなときに、ショートカット集としてまとめておくと使えるかも。
なにしろ、メモとしてじゃなくて、そこから即実行できますからね。便利です。

DBのCSV抽出とグラフ化

DBから検索して、ちょっとした表やグラフを付けたレポートを作成するなんてときにも、このノートで共有しておくことで、効率があがりそうです。

DBのフロントエンドツールとして

phpMyAdminとか、MySQL Workbenchみたいなものの代わりに使えるんじゃないかしら。

作業手順の共有

これまでも、いろんな作業手順をredmineやgitlabのwikiに整理してきましたけど、コマンド実行を含んだ作業手順なんかは、このノートで共有するのも悪くないですね。

保守作業の起点に・・・

社内の踏み台サーバーにインストールして、そこ起点の定型作業を、ノートから実行できたりすると、使える局面が結構あるような気がします。微妙に全自動にできない定型作業とか、結構ありますからね。

他にもたくさん、活用アイデアが出てきそうです。 早速つかってみてください。

即、導入したい場合は、Windows版やMac版を普通にインストールして、追加モジュールを追加していくとよいと思います。

でも、その前に、ちょっと試してみたい人のために、Jupyter NotebookのDockerコンテナを用意しました。サーバー内で使いたい場合も、Dockerコンテナになってるとサクッと導入できて便利だと思います。
このコンテナは、SQL用のモジュールを入れてあるので、mysql で SQL を実行して、テーブル形式にノート保存することができます。
お試し版としては、ちょうどよいと思います。どうぞ、使ってみてください。
https://github.com/altus5/jupyter-mysql

The post Jupyter Notebookを普段使いして仕事効率化する first appeared on 株式会社Altus-Five.

• 自宅サーバーをベーシック認証でユーザー限定で運用をしているのだが、なんとなく気持ちが悪いのでSSL化したい
• モバイルの確認のためにステージング環境をIPアドレスの制限付きで公開しているが、独自CAのSSLで、いつも警告が出るので、警告の出ないSSLにしたい

こんな状況下なら、使えるレシピになるかもしれません。
少なくとも、私は、これで、Let’s Encryptを使ってます。

Let’s Encrypt について

無料で正規のSSLが作成できると言ったら、Let’s Encrypt です。
2016年4月に正式なサービスが開始されて、もう1年以上になります。

Let’s Encryptが、どんな仕組みで、証明書を作成するのか、大雑把に説明すると、
証明書を作成するサーバーに、Let’s Encrypt のクライアントソフトウェア（certbot）をインストールして、 certbot と、Let’s Encrypt の認証局とが、双方向から通信して、検証するという仕組みです。
まずは、certbotがキーペアを作成し、つぎに、認証局がワンタイムトークンを発行してcertbotに渡して、 certbotは、そのトークンにキーペアで署名して、認証局に署名付きトークンを通知して、 認証局は、その妥当性を検証するという流れです。

認証方法には、大きく2つあります。

• サイト内の公知の URI に、認証用のファイルを設置する
• DNSレコードに認証用のレコードを追加する

最初の方は、WEBサイトが認証局からhttpでアクセス可能な状態であることが前提です。
公知の URI というのは、/.well-known/acme-challenge のパスで、例えば、example.com なら、 http://example.com/.well-known/acme-challenge/トークン というパスに、署名付きのデータを書き込んで 配置しておいて、認証局がそのファイルを取得して、値を検証するという方式です。 certbot自身が一時的にWEBサーバーになることもできるし、既設のWEBサーバーを使う方法も可能です。

2つ目の方は、certbotが、DNSのtxtレコードにデータを書き込んで、認証局はDNSのレコードを読んで、検証するという方式です。

非公開サイトの場合は、認証局からもアクセスできないため、2つ目のDNSを使った方法を選択することになります。

Let’s Encryptは、無料でSSLが使えてありがたいのですが、証明書の有効期限が、90日と短いので、 そのサイトを長期運用する場合には、証明書の更新が自動化されていることが、必須となります。

※大雑把で間違った説明があるかもしれませんので、正しくは、Let’s Encryptのポータルサイトを参照してください。

certbotとdehydratedを内包したDockerコンテナ

2016年4月時点の certbot では、まだ、DNS方式の認証処理が、実装されていません。
certbot には、認証局とのやり取りをする前後で、独自の処理を施せる hook script という仕組みが用意されているのですが、 その仕組みを利用して、DNS方式をスクリプト化したのが、 dehydratedになります。

certbotをインストールしたり、dehydratedをインストールしたり、それらの使い方を知るために、 さらに、検索して、そのための手順が書かれた記事を渡り歩いて・・・、たぶん1日では終わりませんね。

そこで、Docker が使えることが前提になりますが、コマンド1発で、証明書が作成できるDockerコンテナをご紹介します。 https://hub.docker.com/r/willfarrell/letsencrypt/

このコンテナには、certbotと、dehydratedが入っていて、DNSにAPIでアクセスして自動化しています。 使えるDNSは、Route53と、CloudFlareです。

CloudFlareを使った証明書作成方法

APIを使うために、CloudFlareのアカウント情報をテキストファイルに用意します。
letsencrypt.env として保存してください。

# defaults to `staging`, use `production` when ready.
LE_ENV=production
#LE_ENV=staging

# CloudFlare
PROVIDER=cloudflare
LEXICON_CLOUDFLARE_USERNAME=アカウント（ログイン時のメールアドレス）
LEXICON_CLOUDFLARE_TOKEN=Global API Key（※）

※ログインしたら、My Settingsのページに Global API Key があります。

docker run で実行します。

docker run \
  --env-file letsencrypt.env \
  -v /etc/ssl:/etc/ssl \
  willfarrell/letsencrypt \
  dehydrated \
    --accept-terms \
    --cron \
    --domain example.com \
    --out /etc/ssl \
    --hook dehydrated-dns \
    --challenge dns-01

これで、/etc/ssl に証明書が作成されました。

Route53を使った証明書作成方法

AWSのアカウント情報をテキストファイルに用意します。
letsencrypt.env として保存してください。

# defaults to `staging`, use `production` when ready.
LE_ENV=production
#LE_ENV=staging

# AWS
PROVIDER=route53
LEXICON_ROUTE53_ACCESS_KEY=アクセスキー
LEXICON_ROUTE53_ACCESS_SECRET=アクセスシークレットキー

そして、Route53の場合は、APIのアクセス権限として、以下の権限を設定してください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "route53:ListHostedZonesByName"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "route53:ChangeResourceRecordSets"
            ],
            "Resource": [
                "arn:aws:route53:::hostedzone/${HOSTED_ZONE_ID}"
            ]
        }
    ]
}

docker run は、CloudFlare用と同じです。

nginxへの設定例

/etc/ssl に証明書を作成して、nginxにその設定するなら、次のような設定になります。

server {
  listen 443 ssl;
  ssl on;

  ・・・

  ssl_certificate /etc/ssl/fullchain.pem;
  ssl_certificate_key /etc/ssl/privkey.pem;

  ・・・
}

証明書の更新

上述した docker run のコマンドを再実行すると、証明書が更新されます。
30日以内の再実行は、証明書の更新は行われず、認証局に無駄な負荷をかけないようになっているようです。
逆に言うと、デイリーで cron に設定しても、大丈夫です。

ただし、証明書が新しくなった場合は、それを使っているWEBサーバーは、再起動しないといけません。
私の場合は、docker run のコマンドとWEBサーバーの再起動をセットにしたスクリプトを用意して、cronに設定しています。

あとがき

dockerを使うと、いろんなものをインストールしなくてよいので、私は、とても好きなんですよね。
何かと、dockerコンテナ化したくなります。

それから、記事を書いていて思いついたんですが、上記で紹介したdockerコンテナを使うと、証明書が作成されるディレクトリを、ドメイン毎に、別々のボリュームでマウントすると、1つのサーバーで、楽に、複数のドメインの証明書を管理できます。 そのサーバーで、nginxでリバースプロキシーしたら、社内の開発用サーバーを無理なくSSL化できそうです。

よろしければ、お試しくださいませ。

The post 非公開サイトをLet’s EncryptなDockerコンテナでお手軽にSSL化する方法 | 開発環境のスピード構築のために first appeared on 株式会社Altus-Five.

docker-registry を使って、 Docker Hub のミラーリングを行います。
次の組み合わせで、動作確認しています。

• docker-registry 2.1
• 設置先サーバー: centos7

docker-registry を配置するサーバーは、 proxy.altus5.local に配置するものとします。

この説明でのディレクトリの構成は、このようなになります。

/opt
  /certs             ・・・SSLの証明書
    ca.pem
    ca-key.pem
    server.pem
    server-key.pem
  /cfssl
    /conf            ・・・SSLの証明書を作成するための設定ファイル
      ca-config.json
      server.json
  /docker-registry   ・・・Docker Registry を実行する場所
    /data              ・・・キャッシュしたイメージの保存場所
      config.yml         ・・・Docker Registryの設定ファイル

この記事は、以下を参考にしました。

• https://blog.docker.com/2015/10/registry-proxy-cache-docker-open-source/
• https://docs.docker.com/registry/recipes/mirror/
• http://docs.docker.jp/registry/recipes/mirror.html

docker-registry の設定

docker-registry の config.yml を取り出して、cacheプロキシー用に、編集します。

# mkdir -p /opt/docker-registry/data
# cd /opt/docker-registry

# docker run -it --rm --entrypoint cat registry:2.1 /etc/docker/registry/config.yml > ./data/config.yml

設定のポイントは、次の2点。

• http/tls にサーバー証明書のパスをセット（証明書は後で、このパスに作成します）
• proxy の設定を追加

編集後は、こんな感じになります。

version: 0.1
log:
  fields:
    service: registry
storage:
  cache:
    blobdescriptor: inmemory
  filesystem:
    rootdirectory: /var/lib/registry
http:
  addr: :5000
  tls:
    certificate: /certs/proxy.altus5.local.pem
    key: /certs/proxy.altus5.local-key.pem
  headers:
    X-Content-Type-Options: [nosniff]
health:
  storagedriver:
    enabled: true
    interval: 10s
    threshold: 3
proxy:
  remoteurl: https://registry-1.docker.io

SSL証明書の作成

docker-registry を、SSLにするために、独自CAで証明書を作成します。
次のコンテナを使うと、素早く作成できます。あわせて、使ってみてください。
https://hub.docker.com/r/altus5/cfssl/

まずは、設定ファイルのサンプルを取り出します。

# mkdir -p /opt/cfssl/conf
# cd /opt/cfssl
# docker run --rm -it \
  -v $(pwd):/srv/cfssl \
  altus5/cfssl:0.5.2 \
  cp -r /opt/cfssl/conf /srv/cfssl/

/opt/cfssl/conf が作成されました。
それぞれ、ご自身の環境にあわせて、書き換えてください。

• 独自CAの証明書の設定（/opt/cfssl/conf/ca-csr.json）
  こちらは、ご自分の組織に書き換えるとよいと思います。
• サーバー証明書の設定（/opt/cfssl/conf/server.json）
  CNは、上記のものと同じにしておいて、
  hosts のところには、docker-registry を設置するサーバーのホスト名を設定します。

{
"CN": "altus5.local",
"hosts": [
  "proxy.altus5.local"
],
"key": {
  "algo": "rsa",
  "size": 2048
}
}

そして、証明書を作成します。

docker run --rm -it \
  -v /opt/certs:/etc/cfssl \
  -v /opt/cfssl/conf:/opt/cfssl/conf \
  altus5/cfssl:0.5.2 \
  gen_server_cert.sh

/opt/certs に証明書が作成されました。

docker-registry を起動する

docker-composeで起動します。
docker-compose.ymlを次のように作成します。
vi /opt/docker-registry/docker-compose.yml

version: '2'
services:
  registry:
    restart: always
    image: registry:2.1
    ports:
      - 5000:5000
    volumes:
      - /opt/docker-registry/data:/var/lib/registry
      - /opt/docker-registry/data/config.yml:/etc/docker/registry/config.yml
      - /opt/certs:/certs

docker-compose で起動します。

cd /opt/docker-registry
docker-compose up -d

docker-compose logs でエラーがないことを、 確認します。

クライアント側の設定

任意のクライアント端末で行います。
dockerクライアントがプロキシーを向くための設定です。
vagrantでvmを起動している場合は、vmの中で行ってください。

独自CAの証明書インストール

証明書を取得します。

scp hoge@proxy.altus5.local:/opt/certs/ca.pem .

独自CAの証明書のインストールは、それぞれの環境に合わせて、行ってください。
ここでは、centos7の場合について、説明します。

sudo cp ca.pem /usr/share/pki/ca-trust-source/anchors/altus5.local.ca.pem
sudo update-ca-trust extract

テストします。

curl -I https://proxy.altus5.local:5000/v2/

HTTP/1.1 200 OK が表示されれば、OKです。もしも、curl: (60) SSL certificate problem: unable to get local issuer certificate と表示されたら、独自CAの証明書のインストールが間違っています。

dockerデーモンの起動オプション設定

dockerデーモンの起動オプションを設定します。
vi /etc/sysconfig/docker

OPTIONS='--selinux-enabled --log-driver=journald --signature-verification=false --registry-mirror=https://proxy.altus5.local:5000 --disable-legacy-registry=true'

OPTIONS に –registry-mirror と –disable-legacy-registry のオプションを、上記のとおり、追加設定します。
設定後、再起動します。

sudo systemctl restart docker

テストします。
先に、 docker-registry の方のログを流します。

cd /opt/docker-registry
docker-compose logs -f

クライアント側で、pullしてみます。

sudo docker pull busybox:latest

クライアント側で、Pull complete と表示されて、 docker-registry の方のログにも、 エラーなく、ログが流れていれば、OKです。

どれくらい早くなった？

キャッシュ効果を測定してみました。

初回

[root@hoge ~]# time docker pull centos:7
Trying to pull repository docker.io/library/centos ...
7: Pulling from docker.io/library/centos
785fe1d06b2d: Pull complete
Digest: sha256:d2c264f34e1a9b415a7ed28df92050acd8b46e827dedf90db61ba75761f6e000

real    2m56.171s
user    0m0.049s
sys     0m0.041s

削除してから、再取得

[root@hoge ~]# time docker rmi centos:7
[root@hoge ~]# time docker pull centos:7
Trying to pull repository docker.io/library/centos ...
7: Pulling from docker.io/library/centos
785fe1d06b2d: Pull complete
Digest: sha256:d2c264f34e1a9b415a7ed28df92050acd8b46e827dedf90db61ba75761f6e000

real    0m16.212s
user    0m0.029s
sys     0m0.026s

初回は、当然、遅いですが、一度、プロキシーにキャッシュされると、早くなることがわかります。
この実験では、 2m56.171s -> 0m16.212s と 2分40秒も節約されました。

たかだか、2分40秒ですが、環境構築中は、なんども、これをやるので、イライラが減って、ありがたいですね。

The post 社内の開発環境でDockerイメージをミラーリングする方法 | 開発環境のスピード構築 first appeared on 株式会社Altus-Five.

受託開発を始めた当初は、社内に開発環境を構築するのに、手間と時間がかかっていました。アプリケーションの開発ばかりやってきて、環境作りを、あまりやって来なかったので、毎回が試行錯誤の連続で、随分と、時間を浪費していたように思います。この当時は、プロジェクトの2初回の進捗報告のときから、すでに、遅れが出ているということも、少なくなかったように思います。

自社内で開発をするためには、この状況を何とかせねば、ということで、カイゼンに乗り出したわけですが、おかげさまで、今では、大きく解消できていると思います。

手順書ライブラリの運用

最初に取り組んだのは、開発環境の構築手順の作成です。
手順書を運用する前は、頭の中に手順があるので、同じ環境を作るだけなのに、担当する人が違うと、それぞれで、試行錯誤していて、「・・・言ってくれれば、教えたのに・・・」という会話が聞こえてきたりして、イライラしたものです。

これは、まだDevOpsが言われる前の話なので、環境を作るというのは、全部手作業でした。 ミドルウェア毎に、インストール時のコマンドや、設定ファイルの修正箇所と、設定値を、文書化して、手順のライブラリ化に取り組みました。

プロジェクト毎の手順書は、手順ライブラリから、必要なところを、コピーして、プロジェクト用の冊子にする感じです。まぁまぁ、うまくいったと思います。

Vagrant と Docker

次に取り組んだのは、Vagrant、Docker です。
上記の手順書ライブラリも、悪くはないけれど、環境を作った後に、ターミナルのログを拾って、手順を起こしていた関係で、たまに、間違った記述があったり、パッケージのバージョンが書かれてなかったりと、手順書のとおりに、環境が作れないことがあるんですね。
Vagrant、Dockerを知った時に、この問題を解決してくれることが、すぐにピンときたので、躊躇なく乗っかりました。

だた、一緒に紹介されることの多い、 chef と ansible は、全面的には、取り入れていません。
この2つのツールについても、チーム内の全員が、学習しないといけないのか？と考えた時に、そこまでは、やりすぎかも・・・という点と、シェルスクリプトだけでも、結構、作れるので、今は chef と ansible については、優先度を落としてます。
何しろ、他にも、やりたいことがたくさんあるので。

イメージの固定化

Vagrant と、Docker を併用した環境準備は、ほぼすべてのプロジェクトで、これらを使うようになりました。かなり浸透しました。
以下は、次に、やろうとしている取り組みです。

開発が進んでいく中で、環境を作り直すことがあります。必要なライブラリが追加されたり、ミドルウェアが追加された時などですが、外部のリポジトリがダウンしてたり、ネットワークが混んでいて、異常に時間がかかったり、外部要因によって、開発が停滞することがあります。
特に、最初の開発環境を作る段階では、何度もダウンロードとbuildを繰り返すので、どこかに、キャッシュできるとよいし、そのキャッシュをチーム内で共有できると、もっとよいと思っています。

さらに、OSS等のマイナーなバージョンアップで、動かなくなったりすると困るので、開発の元にしたライブラリやパッケージを、Dockerイメージの中に封入して、原則、社内リポジトリからの docker pull だけで環境を作れないものか、模索しています。

標準PC

開発用PCを統一するのも、環境構築のスピード化に寄与するかもしれません。
社内では、Windowsでの開発を、原則としています。
Macで作ったから、Windowsじゃ動かないかもです・・・という、めんどくさい会話で時間を無駄にしたくないのが理由で、納品先のお客様の多くが、Windows環境なので、Macじゃなくて、Windowsを標準PCとして、統一しました。
Macを使ってる人の中には、 Windows を嫌う人もいますが、悪くないですよ、仕事には、十分です。

ちなみに、弊社は、全員の PC が Vaio です。
購入時期によってモデルが違うものの、主なスペックは、13インチのノートPCで、Core i7、メモリ8～16Gで、他に、外付ディスプレイを使ってます。
どこに移動しても、Vaio用のACアダプターが、延びているので、デスクの移動は楽ですかね。あまりメリット感が出てませんが。

The post 開発環境を素早く構築する – 自社内での開発に欠かせないスキル first appeared on 株式会社Altus-Five.

その前に、ふと、Dockerコンテナの中で、Dockerコンテナが動くんだろうか？という疑問がよぎった。

できたとしても、親子の入れ子構造にすると、イメージが肥大化するので、兄弟関係で、動かした方がいいんだろうな・・・ということは、なんとなく想像がつくので、コンテナ間で、 docker exec できないものか？と調べてみる・・・。

そして、Dockerコンテナの中で、Docker Clientは、動くらしくて、ホストOSにある /var/run/docker.sock を共有することで、コンテナ内で、ホストOS側の Docker Client と同じ実行結果になることがわかった。
http://qiita.com/minamijoyo/items/c937fb4f646dc1ff064a

ただし、このやり方は、セキュリティ的にリスクがあると警告しているので、本番用には使わないことにした方が良さそうだ。

さて、実験用のコンテナを、3つ用意する。

• base
  作業用のベースコンテナ（ここに、Docker Clientを入れる）
• node
  nodeが入ってるオフィシャルなコンテナ
• ruby
  rubyが入ってるオフィシャルなコンテナ

まずは作業場となる baseコンテナは、 Dockerfile でビルドする。中には、Docker Client を入れる。

Dockerfile

FROM alpine:3.4

ENV DOCKER_CLIENT_VERSION=latest

RUN apk add --update curl bash \
  && rm -rf /var/cache/apk/* \
  && curl -fsSL https://get.docker.com/builds/Linux/x86_64/docker-${DOCKER_CLIENT_VERSION}.tgz > docker.tgz \
  && tar xfz docker.tgz docker/docker \
  && mv docker/docker /usr/local/bin/docker \
  && rm -rf docker \
  && chmod +x /usr/local/bin/docker

alpine を使うと、すごくイメージが小さくて、あっという間に build できる。

あとは、 node と ruby のコンテナも必要だが、 Dockerfile は必要ないので、3つのコンテナあわせて、 docker-compose.yml にまとめる。

docker-compose.yml

version: '2'

services:
  base:
    build: .
    image: altus5/base:latest
    container_name: base
    command: bash
    tty: true
    working_dir: /srv/app
    ports:
      - "4000:4000"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - .:/srv/app
    depends_on:
      - node
      - ruby

  node:
    image: node:7.3.0-alpine
    container_name: node
    tty: true
    working_dir: /srv/app
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - .:/srv/app

  ruby:
    image: ruby:2.3.3-alpine
    container_name: ruby
    tty: true
    working_dir: /srv/app
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - .:/srv/app

そして、次のコマンドで、起動する

docker-compose build
docker-compose up -d

docker ps で見ると、3つのコンテナが起動していることがわかる。

$ docker ps
CONTAINER ID        IMAGE                COMMAND             CREATED             STATUS              PORTS                    NAMES
27dc3a69e82f        altus5/base:latest   "bash"              5 seconds ago       Up 4 seconds        0.0.0.0:4000->4000/tcp   base
4156913e9fb4        node:7.3.0-alpine    "node"              5 minutes ago       Up 5 minutes                                 node
d86a3f65e733        ruby:2.3.3-alpine    "irb"               5 minutes ago       Up 5 minutes                                 ruby

さて、baseコンテナの中で、どうやって、 node を使うか説明する。

#まずは、baseコンテナに bash で入る

$ docker exec -it base bash

# コンテナ内で、 docker ps してみると

bash-4.3# docker ps
CONTAINER ID        IMAGE                COMMAND             CREATED             STATUS              PORTS                    NAMES
27dc3a69e82f        altus5/base:latest   "bash"              10 minutes ago      Up 10 minutes       0.0.0.0:4000->4000/tcp   base
4156913e9fb4        node:7.3.0-alpine    "node"              16 minutes ago      Up 16 minutes                                node
d86a3f65e733        ruby:2.3.3-alpine    "irb"               16 minutes ago      Up 16 minutes                                ruby

# このとおり、ホストOSの docker の出力と、同じになる

# baseコンテナから、nodeコンテナに exec してみる

bash-4.3# docker exec -it node node -v
v7.3.0

# 例えば、/usr/local/bin/node と npm を次のように、スクリプトを作成しておくと

bash-4.3# echo 'docker exec -it node node $*' > /opt/bin/node
bash-4.3# echo 'docker exec -it node npm $*' > /opt/bin/npm
bash-4.3# chmod +x /opt/bin/*

# baseコンテナの中に、nodeがあるかのように動く

bash-4.3# node -v
v7.3.0
bash-4.3# npm -v
3.10.10

実用性があるかどうは、なんとも言えないが、ちょっと、おもしろくないだろうか？
なるほどねー！と思った人は、きっと、 Docker 好きです。

実用性が・・・と前置きしたのは、node の場合は、やってみると、いろいろ問題が出てきたからである。

npm で global にインストールしたときは、node コンテナの中に、インストールされるので、docker exec の起動シェルを、その都度、作成してあげないといけない。

あと、gulp-sass なんかは、node から child_process で ruby を実行するわけだが、node コンテナの中に、docker exec で ruby を起動させるシェルを配置してあげないといけない。

他にも、bowerとか、rootでの実行が推奨されていないものを、どうする？とか。

特に、最後の bower の課題に気づいたときに、これだと、コンテナ起動後に準備することが多くて、結局、Dockerfile 作った方がいいなぁ・・・と感じられたので、試行錯誤するのをやめた。

でも、nodeは、いろいろ、面倒なのだけど、もう少し、コマンド構成が単純なものであれば、Dockerfileを作らずに、docker-composeだけで、間に合わせるということが、できるので、覚えておくと、使えることがあるかもしれない。

The post Docker コンテナ内から他の Docker コンテナに docker exec する first appeared on 株式会社Altus-Five.