NimのTutorial Part1を終えて

とりあえずday1、Tutorial1を進めてみた上でのメモです。
英語はそんなに得意ではないので、@KTakahiro1729 さんの

Nim Tutorial Part Iを日本語訳してみた(前編)
Nim Tutorial Part Iを日本語訳してみた(後編)

に助けられました、ありがとうございます!

環境構築

macOS Sierra 10.12.6

$ brew install nim 
$ nim -v
$ Nim Compiler Version 0.17.2 (2017-09-08) [MacOSX: amd64]

で問題なく入りました。

基本的に記述が簡素

記述がいたるところで簡素です。
言語思想として全てはこれに尽きそうな雰囲気ですが、静的型付け言語として特徴的だと思います。

# 出力の例
echo "Hi, ", name, "!" 
echo "int value: ", $myint #intのキャスト

タイプしやすいし、簡素でいいです。
echoにはimport等も特別必要ないし、スクリプト言語のようにスッとかけます。

# 定義の例 
var 
  x, y: int
  # コメントも可能
  a, b, c: string

let
  x = 0     # x is of type int
  y = 0'i8  # y is of type int8
  z = 0'i64 # z is of type int64
  u = 0'u   # u is of type uint

const
  x = 1
  y = 2
  # コメントも可能で計算もできる
  z = y + 5

type
  MyEnum = enum
    a = 2, b = 4, c = 89

これまたJavaScriptのような、いやそれ以上な手軽さがあってとっつきやすいです。

# 変数オーバーロードの例

type MyPoint = object
  x: int
  y: int

# バッククォートでオーバーロード!!
proc `+`(left: MyPoint, right: MyPoint): MyPoint = 
  MyPoint(x: left.x + right.x, y: left.y + right.y)

var p1 = MyPoint(x: 10, y: 40)
var p2 = MyPoint(x: 20, y: 10)
var p3 = MyPoint(x: 30, y: 80)

var p4 = p1 + p2 + p3
echo "x: ", p4.x, "y: ", p4.y

いままで混乱を避けるためにあまり利用していませんでしたが、これは麻薬的な効果がありますね。。
ここまで簡素だとやはり使ってみたくなってしまいます。

関数定義が柔軟

NimではProceduresと称されています。
もちろん記述は簡素なのですが、細かいところで気が利いてるなぁと思いました。

# 返り値の省略
proc sumTillNegative(x: varargs[int]): int =
  for i in x:
    if i < 0:
      return # 暗黙のresult返却
    result = result + i # 暗黙のresultの打ち消し

echo sumTillNegative() # echos 0
echo sumTillNegative(3, 4, 5) # echos 12
echo sumTillNegative(3, 4 , -1 , 6) # echos 7

これまたJavaScriptみたいに扱えて感触良いです。

# 可変引数
proc myWriteln(f: File, a: varargs[string, `$`]) =
  for s in items(a):
    write(f, s)
  write(f, "\n")

myWriteln(stdout, 123, "abc", 4.0)
# 定義だけで勝手にキャストしてくれる
myWriteln(stdout, [$123, $"abc", $4.0])

これも地味にすごいと思いました。

文字列の最終位置参照がエラーにならない

いいのか悪いのかちょっとよくわからないのですが、NimでのStringは最終位置が0となるようで、そこへのアクセスを行ってもエラーにならないようです。

var str: string = "abc"
for i in 0..len(str):
  echo $str[i] # str[3]でエラー吐かない

地味にコード量減って意外と活用する箇所がありそうな雰囲気です。

実際に触ってみてと次にやること

チュートリアルをやっていて思ったのは、言語を書くというプリミティブな行動は、創造性があり楽しいものであるべきだということでした。
月並みですが、初めてプログラミングを始めた頃のような気持ちを取り戻せていいですね。
これはきっとRustでもPythonでもGoでも同様のことを思ったと思いますが、Nimの場合圧倒的に無駄な記述を無くすことにひとつのアイデンティティを感じます。
シンプルな記述はコードを書いていても気持ちいいので、もう少しNimに付き合ってみたいなという感想です。
あと、想像していたよりはドキュメントも揃っているイメージです。
1,2年前くらいとは少し状況は変わっているのではないでしょうか。

次はTutorial2と思ったのですが、冒頭で

Note that this document is somewhat obsolete as the manual contains many more examples of the advanced language features.

とあるのでマニュアルの方を参考にしつつ、実際に簡単なWebアプリを作ってみたいと思います。

全く関係ないですが、はてなブログシンタックスハイライト対応言語にNimがあったのが地味にびっくりでした。

バックエンドの言語採択についてリサーチ

私の言語としてのスキルアセットは、html DOMのためのJavaScriptC#を利用したXamarinといった主にフロントエンドなのですが、今年はバックエンドの実装からインフラの管理を学習したいなと思っていて、その辺りのリサーチをしています。
個人開発でWebアプリ作って、そのナレッジを会社還元したいなという今年のぼんやりした目標です。
そもそもバックエンドはPHPを軽く触る程度の知識なので、改めて何を採択するかというところが最大の悩みどころです。
リサーチ前はPythonかGoで悩んでいたのですが、色々ありますね。
よく知らなかったけれどトレンドな言語として、NimRustについてメモしておきます。
実際に触らないとなんとも言えないことは多いのですが、ネットの情報からひとまず机上の空論してみました。

Nim

とにかく早い!、軽量!ってのが目立ったり、なかなか刺激的な記事があったりで、Nim一択じゃんってなりかけました(単純)
が、まぁ落ち着いてみます

気になる点

  • 実用としては流行ってない
  • 10年開発してるけれど、2018/1/10現在0.17.2でいつメジャーリリースするのかよくわからない雰囲気

ポジティブ

  • 構文かシンプルそう
  • コンパイル時間が短い
  • やってる人が少ない分、先行優位性はある
  • いろいろな人が早いって言ってる

Rust

7年程度の開発で、Mozillaが参入していてバージョンも2018/1/10現在1.23。
Nimと比較すると日本でのユーザ数も多いですね。

ドキュメントも豊富にありながら、導入を補助するような記事もたくさんあって大きくつまずくことはなさそうな感触がありました。
ただ、トレイト、ゼロコスト抽象化、所有権システムといった他言語で聞きなれないような明示的な概念があり、言語理解自体は少し時間かかりそうです。

気になる点

  • 言語取得の障壁が多そう

ポジティブ

NimとRustググってみて

PythonかGoで比較してみるつもりが、最終的になぜかNimとRustをググっていました、、
まぁどうせやるなら、低レイヤーかつポテンシャルが高い言語覚えたいなという気持ちが強いってことですかね。
静的型付けに抵抗はないので問題ないです。
改めてNimとRustで比較対象してみると、安定感という意味でRustかなぁって印象でした。
個人開発では、勉強という意味である程度言語習得のためのコストはストレスになりませんが、それでもNimだとやはりつっかかるコストが多くストレスになりそうかなといった感じです。
しかしあくまで机上の空論なので、一旦Nimを触ってみて考えてみようかなという現状です。

WordPressで全面的にVue.jsを導入してみた(SPA実装ではない)

以前SPA実装のWordPress案件に関わったのですが、Rootingをフロントで持つことが強いられる一方でWordPress独自のURL排出にバックエンドとフロントエンドどちらも意識しないといけないことが結構大変でした。

itaoyuta.hatenablog.com

なのでWordPress実装にVue.jsを利用する場合SPAはないなという所感だったのですが、その一方でどのように関われるか考えた結論、単純に都度ページを読み込むスタンダードな実装がほとんど文句なくよかったです。

開発環境について

WordPress: 4.9.1
WebPack: 3.8.1
Vue: 2.5.3

WordPress独自テーマのViewファイルの感じ

<?php get_template_part( 'partials/head' )?>

<div id="top"></div>

<script src="<?php bloginfo('template_directory'); ?>/js/top.bundle.js"></script>

<?php get_template_part( 'partials/foot' )?>

このような感じで、WebPackでまとめられたページごとに生成されたVueファイルを読み込みます。
そして中身のvue側で、WP REST APIを利用し必要な投稿データ等を取得してページを構築します。

Vue.js側の構成

f:id:itaoyuta:20171228133936p:plain

起点となる共通app.jsを用意しつつも、ページごとのjsを用意して、そこから専用のvueコンポーネント及び共通コンポーネントを拾ってくるような形で構成しています。

メリット / デメリット

  • メリット
    • 組み込みという無駄な作業が発生しないためbackendとfrontの無駄な共有ごとが減る
    • phpにフロントのソースが混入しないので、見渡しがよい
    • backend側の稼働コストが極端に低いがfrontの稼働コストはそこまで変わらない
  • デメリット
    • Vue.js自体の学習コスト
    • 受託作業の場合納品形態に念のため確認をとった方がいいかも
    • ページ遷移時、ヘッダー等の共通パーツも仮想DOMとして再作成された上でレンダリングされるタイミングがメインフローのdisplayed以降に評価されているからか、微妙にページ遷移したときにチラついて見える*1
      • 静的に記述されたDOMであれば、DOMとStyleを事前評価した上で前ページと同様だった場合レンダリングされた場合チラつきがおきない

大きいデメリットで言えば、ページ遷移の際のチラつきを感じる場合がある箇所かと思いますが、これは実装方法を探ればなんとかなりそうな気もしています。
具体的に言うとヘッダー等条件によってアニメーションをつけたりする場合、その条件評価を待ってしまうため、非同期でとってくるデータをまったりしてしまうと、その間表示されないみたいなことがおきている感じがします。
このあたりは、要調査といった課題となりました。

まとめると

トータルで見ると、積極的に採用しない理由はないくらいよい感じなので、しばらくこのスタイルで開発してみたいと思っています。
backendがAPIのみ考えればよくて、フロントがデータを元に画面を構築していく分業が非常にシンプルに終わりそうでいい感じです。
さらに求めるなら、GraphQLでフロントがデータオブジェクトを好きに生成するところまでいければ最高ですが、ひとまずはREST APIでこのスタイルが根づけば良い感じですね。

Azure App Service / WordPress on Linux (preview) を探る - 2

2018/4/12現在、Azure App Service / WordPress on Linux (preview)はpreviewではなく正式リリースされているようです

f:id:itaoyuta:20171020232853p:plain

前置き

itaoyuta.hatenablog.com

前回に引き続きAzure App Service / WordPress on Linux、今回は開発環境 / 運用とデプロイフローについて見ていきます。

2. 開発環境 / 運用とデプロイフロー

Dockerと参照先のWordPressリポジトリでリモート環境を再現する

前回解説した通り、Azure App Service自体のOS/ミドルウェア構成は、Dockerのimageをベースに作成されています。
また、アプリケーションリソースはgithubで管理されています。
local環境でも同様なimageを参照して、アプリケーションリソースをクローンすれば、リモートと同じ環境を用意することができますね。

前回調べた通り、Azure App Service / WordPress on Linuxで参照されているDocker imageとアプリケーションリソースは以下の通りです。

docker-compose.yml

appsvc/apps:apache-php-mysql-0.2では、データサーバをbuilt-inのローカルもしくはリモートを選択できます。*1
開発環境では、簡易に制作を開始できるbuilt-inのローカルを利用してみます。
これは、環境変数DATABASE_TYPEにlocalを指定することで実現できます。
また、Docker Containerにその他必要な環境変数をあらかじめ設定しておきます。

version: '2'
services:
  webapp:
    image: appsvc/apps:apache-php-mysql-0.2
    volumes:
      - ./:/var/www/wwwroot
    ports:
      - 80:80
    environment:
      DATABASE_TYPE: local
      PHPMYADMIN_USERNAME: phpmyadmin
      PHPMYADMIN_PASSWORD: MS173m_QN

PHPMYADMIN_USERNAME及びPHPMYADMIN_PASSWORDサービスのデフォルトを利用しています。

wp-config.php

次に、wp-config.phpの作成です。
ここでは、前回説明したデフォルトで紐づけられているWordPressリポジトリに乗っ取ってwp-config.phpを編集します。
L23〜L26

$connectstr_dbhost = 'local';
$connectstr_dbname = 'wpapp';
$connectstr_dbusername = 'phpmyadmin';
$connectstr_dbpassword = 'MS173m_QN';

DBの作成

docker-compose.ymlとwp-config.phpの準備が整ったら、docker-compose up -dでコンテナを立ち上げます。
これだけだと、まだDBが作成されていないため"Error establishing a database connection"と表示されてしまいます。

f:id:itaoyuta:20171030165751p:plain

立ち上がったコンテナ内に入り、直接DBをcreateしていきます。
このあたりはDockerfileを利用する等して作業の単純化をおすすめしますが、一旦流れをシンプルに説明するためにここでは直接作成しにいきます。
docker exec -it wordpressazuremaster_webapp_1 bash コンテナに入ったら、build-inのDBに対して新規作成していきます。

$ mysql -u root
$ CREATE DATABASE wpapp;
$ exit

これで全ての手順が整ったので、改めてdocker-machineのホスト先へアクセスしてみると

f:id:itaoyuta:20171030165812p:plain

無事に成功しました。
ここまでの成果物をアップして、次にリモートと連携をとります。
注意点として、wp-config.phpは環境ごとに設定が違うため.gitignoreで除外してあります。

github.com

補足

今回の構成では、毎回DB作成しないといけない、データが永続化されない、といった点がありますが、もちろんDockerの構成次第でその辺りはクリアできます。
また、プロジェクトによってはドキュメントルートを変更したいといったミドルウェアの設定にも影響するものもありますが、Azure App ServiceではDocker Hubを参照することもできるので、自分でカスタマイズしたDocker imageを参照させることでいくらでも設定できます。
あまり突っ込んでカスタマイズしていくと、PaaSではなくなってくるような気もしますが、、publicに晒したくないファイルの管理のためにも、ドキュメントルートの変更くらいはしたほうが運用都合よさそうですね。
また、wp-config.phpといったgit管理したくない設定ファイル系はFTPでアップすることもできます。

リモートのアプリケーションリソース設定を変更する

先ほど作成したgitリポジトリを開発リポジトリと仮定して、次にAzure App Service内で環境を紐づけます。

リポジトリの設定

デプロイオプションから現在紐づいているgitリポジトリを切断します。

f:id:itaoyuta:20171030171811p:plain

新しく、先ほど設定したリポジトリを紐づけます。

f:id:itaoyuta:20171030171850p:plain

以上で、上記リポジトリmasterをwebhookされた状態になっているので、なにかしら変更があれば自動的に取り込まれるようになりました。
簡単すぎる、、、

wp-config.phpのアップ

先ほど編集した箇所と同様の箇所を、リモート環境の環境変数に合わせたwp-config.phpFTPを利用してアップします。
反映するべき環境変数は、"設定 -> アプリケーション設定"に記述されています。

f:id:itaoyuta:20171030190709p:plain

FTPのアイパスは、"デプロイメント -> デプロイ資格情報"からAzure全体にひもづくユーザアカウント設定をした後、"設定 -> プロパティ"から確認できます。

f:id:itaoyuta:20171030191207p:plain

こちらの情報で接続して、/site/wwwroot/配下にwp-config.phpをアップして正しく設定されていると

f:id:itaoyuta:20171030191554p:plain

無事に接続されます。

運用とデプロイフロー

デプロイメントスロット

Azure触ったっことある方には全然新鮮味のない話になってしまいそうですが、 今回最も感動したのがこのデプロイメントスロットの存在です。
基本ここまで何度か説明している通り、Azure App Serviceはコンテナベースで動いています。
デプロイメントスロットは、コンテナの作成というイメージに近いです。
そして、作成されたコンテナに対してスワップという機能を用いてプロダクションとステージングの切り替えといったことがコンテナ単位で行われます。
Azure App Service内のみでGUIベースでの簡易オーケストレーションツールが付帯されているような感じです。
これがめちゃくちゃ便利で、PaaS環境のことから遠ざかっていた私としては新鮮に感じました。

スロット作成して
f:id:itaoyuta:20171030180137p:plain

スワップ
f:id:itaoyuta:20171030181043p:plain
f:id:itaoyuta:20171030182159p:plain

もう一度押せば、本番環境がスワップ前の元に戻ります。
コンテナ自体は維持したまま、参照先のみ変更するようなイメージなので、デプロイ自体も全く時間かかりません。
さらに、スワップさせない環境変数といったものも設定できます。
まだ実運用している案件はないのですが、これを利用して相当スムーズなデプロイフローを構築できるのではないかと思います。

本来このようなデプロイフローは、k8sで構築したり、ちゃんとコードを書いて運用に回したりするものですが、プラットフォーム自体がこのようなサービスを提供していてくれれば、ものすごい効率いいですね、保守管理付きです。

振り返り

改めて振り返って、Azure App Service非常に使えるなという印象でした。
しっかり調べたら他2大サービスも近いことできそうですが、UI UXに関して言うと個人的にはダントツで一番使いやすくてわかりやすかったです。
また、コンテナのホットデプロイといった本来シンプルなものをシンプルに機能提供できている点についても、とてもフレンドリーに扱いやすかったです。
なにより触っているだけでサービスが理解できてきてワクワクしてくる、これがサービスの本質だなぁと肌で感じることができました。
これを機に、自社案件受託案件問わず積極的にAure App Serviceの提案をしていってみようと思っています。
また比較として他のPaaSも気になりますが、それはまた別の機会に調べていきたいと思います。

Azure App Service / WordPress on Linux (preview) を探る - 1

2018/4/12現在、Azure App Service / WordPress on Linux (preview)はpreviewではなく正式リリースされているようです

f:id:itaoyuta:20171020232853p:plain

前置き

受託案件で、Azure縛りでWordPressを立てる必要があって検証しました。
Azureについては、"AWS, GCPと並ぶ大きいサービス"くらいの認識だったので、実際に触るのは初めてです。
実際触っていて感じたのは、想定以上にUIがよくて、GUI操作感について個人的には3大クラウドサービスで一番使いやすいと思いました。
また、Azureが提供するデプロイ機構が本当に素晴らしく強力かつシンプルで、機会があれば今後積極的に導入したいと思うほどよくできています。
この辺り、大企業の提供するPaaS環境*1の強いところですね。

個人的にはとても良かったので、WordPress開発手法のひとつとして参考にしていただけたらと思い、チュートリアルな要素も含めつつ記事化してみようと思います。

今回の記事は、チュートリアルな要素もありつつでちょっと長くなりそうなので、2記事に分割して更新します。

  1. サービスとOS/ミドルウェア
  2. 開発環境 / 運用とデプロイフロー

と展開しました。
この記事では、Azure App Service / WordPress on Linux (preview)そのものについてと、提供されるOS/ミドルウェアの解説まで行きます。

1.サービスとOS/ミドルウェア

Azure App Service / WordPress on Linux (preview)について

MicrosoftのサービスAzureの提供するAzure App ServiceというPaaS環境を提供するサービスの中の、WordPress on Linux (preview) というひとつのパッケージです。
長いですね、、文字にするとすごく長くなってしまい、説明するときに若干言いづらいのです。
一口にAzureといってもサービス全体は膨大ですね。。
全体像に関してはこちらがわかりやすかったです。

App Serviceの他パッケージについて

App Serviceはいくつかのパッケージを提供していて、いくつかカテゴライズされています。
今回利用するWordPress on LinuxWeb Appsカテゴリーに属していて、カテゴリー自体では2017年10月時点で56のサービスを提供していました。
カテゴリー自体は9あるので、サービスのバリエーション豊富さがよくわかるかと思います。
同じCMS系で言うとDrupalがあったり、単純なphp x MySQL環境とかもあったりします。

また、WordPress on Linux と明示していることからわかる様に、on Windows*2が元々存在していて、WordPress on Linuxパッケージが提供され始めたのは2017年3月あたりと、ここ最近の出来事のようです。
WordPress側が推奨環境にWindowsを置かない限り、いずれWindows on Wordpressパッケージは淘汰される運命にありそうな予感がします。

運用を想定する場合気になるpreview印について

あくまで検証から得られた個人的な見解で、正式なリリース情報ではありませんというのを前提に話を進めると、要点としては

  1. App Service on Linux on Wordpressによるプロバイダー側未検証
  2. Azure Database for MySQL preview

があると理解しています。 この部分以外に関しては、既存のpreview印がついていない既存パッケージと同様なためです。
※もし上記以外の理由が考えられる場合は、ご指摘いただきたいです。

App Service on Linux with WordPressによるプロバイダー側未検証

App ServiceはそもそもWindows OS環境からスタートしているっぽく、App Service on LinuxがGA*3されたのは2017年9月と、つい最近の出来事です。
そのリリース環境に対しての、WordPress動作確認/サポート体制がまだ十分に完了仕切っていないのではないかと推測されます。

Azure Database for MySQL preview

WordPress on Linuxでは、データベースに

を選択できます。
Azure Database for MySQL previewpreviewを選択肢として提供している部分が、上位概念のWordPress on Linuxへ伝播してそれ自体もpreview扱いになるのはわかりやすいですね。
Azure Database for MySQL preview自体のpreview制約はこちらの通りです。
運用パターンによって厳しいところはありそうですが、ゲームのような複雑ユーザアクションが絡んだり、時間によってデータ蓄積の増減性があるようなものではない、静的なサイトではまず問題なさそうかなと思いました。

OS/ミドルウェアについて

データベースはアプリ初期構築時に選んだので、MySQL5.7ですが、それ以外はどうなっているのでしょう。

まず大前提として、App ServiceはDocker imageを基に構築されます。
なので、そのDocker imageを辿ればOS/ミドルウェアに何を利用しているか、独自に何を設定しているのかを確認できます。
それでは追って確認していきます。

Azure App Service / WordPress on Linux (preview) を作成

※Azureへの登録等はすっ飛ばします。

まず、Azure portalへログインして左カラムからApp Serviceを選択してWordPress on Linux (preview) を選択し、必要事項を記入してアプリを作成します。

f:id:itaoyuta:20171020212733p:plain

f:id:itaoyuta:20171020213304p:plain

今回は、Azure Database for MySQL previewを利用してみることにしました。
余談ですが、リージョンは東日本と西日本を比較すると3割ほど料金に差がでてくるそうです
日本限定のサービスで、そこまでレイテンシを気にしないサービスなら西日本がよさそうですね。

f:id:itaoyuta:20171020214215p:plain

デプロイされてます、作成にはまぁ5分くらいかかりますので気長にまちましょう。

紐づいているリソースを調べる

App Service作成が完了して、管理画面に入ると色々項目がでてきます。
ここでまず最初にアプリケーション設定を見て見ると

f:id:itaoyuta:20171020215422p:plain

Linux アプリ用のスタック構成は、コンテナーで定義します。

とあります。クールですね。
検証時に色々調べていたのですが、ドキュメントルート等ここで個別に設定したりするパッケージもあるようです。
ですが、このAzure App Service / WordPress on LinuxではDockerで設定しとけと。
時代はDocker基礎知識必須ですね。
新しいサービスは、コンテナ技術をベースに作られていることがよくわかりました。

そしてDocker コンテナーへ移動してみると

f:id:itaoyuta:20171020215956p:plain

バッチリありますね。

https://hub.docker.com/r/appsvc/apps/tags/
を辿って
https://github.com/Azure-App-Service/apps/blob/master/apache-php-mysql/0.2/Dockerfile
です、見えてきました。

Dockerのイメージって、概念的にはなるべく細切れにして、複数を構成してオーケストレーションするってのが基本かなという知見でした。
が、こういう扱い方というかこうやってひとつにまとめちゃうってパターンも、場合によってはありだなと思いました、面白いです。

構成を抜き出して見る

最終的な結論として、設定されているDocker imageのDockerfileから2017年10月時点でAzure App Service / WordPress on Linux (preview)として提供されているOS/ミドルウェアのデフォルト構成は

ということがわかりました。

WordPressパッケージの参照を確認する

ついでに、同梱されているWordPress環境を調べて見ます。
こちらは非常に簡単で、概要 -> 外部リポジトリプロジェクトで確認できます。

f:id:itaoyuta:20171030150057p:plain

github.com

こちらのリポジトリのmaster最新が上がるたびにwebhookでリソースの更新がかかるようになっています。
このあたりは、「2.開発環境 / 運用とデプロイフロー」で説明するとして、今回はこのリソースが利用されていることだけわかれば問題ありません。

次回は、開発環境について確認していこうと思います。

itaoyuta.hatenablog.com

*1:ソフトウェアを構築および稼動させるための土台となるプラットフォームを、インターネット経由のサービスとして提供する。 Wikipedia

*2:正式にはAzure App Service / WordPressです

*3:General Availabilityの略。GAされる大きな恩恵のひとつにはSLAが保証されることがあります。

AnsibleのPlaybookのテストにDockerのコンテナを利用した話

今更感ありますが、Ansible触る機会があったので触って見ました。

開発環境について

$ docker -v
$ Docker version 17.06.0-ce, build 02c1d87

$ docker-machine -v
$ docker-machine version 0.12.0, build 45c69ad

$ ansible --version
$ ansible 2.4.0.0

なぜAnsible?

プロダクションのデプロイに対して、Docker環境構築するのはちょっと重い(予算的にも規模的にも)ことはまぁあると思います。
ただ、development, staging, production とミドルウェアの環境構築はコードで管理したい。
そこでの最適解が、現状Ansibleかなと考えます。

なぜDocker Container?

色々見ていると古い情報が多いっていうのもありますが、Ansible PlaybookのテストはVagrantVirtualbox立てるのがいいですと書いてあるところが多かったです。
まぁそこはしかし、Virtualboxのダウンロードがめちゃくちゃ時間かかります。
これ、今回CentOS7のPlaybookだけれど、次回CentOS6だったら?Ubuntu環境,Windows環境だったら?と考えると絶望的な気分になりました。
そこでDocker Containerですよね。

実際にやってみた

Ansible構成

CentOS: 7
Apache: latest
MySQL: 5.7
PHP: 7.1
redis: latest
git: latest

調査

早速調査したところ、感謝すべき先人達がたくさんいますね。
特に参考になったのは、GMOのAdachiさんが書いてくださったこちらの記事です。
この記事通りやれば、問題なく立ち上がると思います。
私の場合は、先にコンテナを立ち上げていて、その立ち上げ方に問題がありいくらか時間を使ってしまいました。
以下にログとして残しておきます。

service httpdがdocker containerで動かない

導入検証時、centos:7 コンテナを普通に

$ docker run --name testcontainer -it -d centos:7 

として立ち上げていたのですが、この立ち上げ方に問題がありました。
こちらの記事に詳しいのですが、centos7ではsystemctlがデフォルトで効かない都合上、httpdをserviceから起動させる箇所で

$ fatal: [testcontainer]: FAILED! => {"changed": false, "failed": true, "msg": "Could not find the requested service httpd: host"}

と言われ続けました。

$ docker run --name testcontainer --privileged -d centos:7 /sbin/init

と、特権モードでコンテナを作成して/sbin/initで起動しておくことで解決できます。
Docker Containerのplaybook動作確認時、service絡みで同様にエラーを吐く場合は、もしかしたらcontainerの起動方法で解決できるかもしれないです。

今回の成果物の簡易版を置いておくので、よかったら参考にしてみてください。

改めてVirtualBoxとの比較

Playbook検証環境の用意、実は最初Virtualboxダウンロードをしようとしていたのですが
VirtualBoxのダウンロード60分くらいに対してDockerのimage pull30秒くらい
で終わりました(笑)
また、Playbookの設定ミスってOSのクリーンインストールからやり直したいって場合も、vagrant destoryからvagrant upと比較して、コンテナの再作成も相当差があるのではないでしょうか。
せっかくDocker環境があるなら、手軽に再作成できるのでPlaybookの検証環境に最適かと思っています。

CINRAでの活動について

CINRAでは、受託案件及び自社案件本当に様々なインフラ環境があります。
以前までは、Vagrant + Virtualboxで開発環境を用意していたのですが、1年弱前くらいからは開発環境の構築は全てDockerで構築するようになってきました。
これによって、

  • 実装エンジニアの環境構築が早くなるので初動が早くなった
  • 比較的過去の案件でも問題なく環境構築を再現できる

といったメリットがあり、環境構築周りが非常にスムーズになりました。
この辺りは、マネージャー濱田にいつか話して欲しいトピックだったりします。

GASのプロジェクト管理と関数名の規則といったプロパティ管理について

GoogleサービスをプログラムからアプローチできるGAS*1は、非常に便利で人気がありますね。
日本の記事もたくさんあるので特別書く必要はないかなと思ったのですが、以前自分がはまった

  • GASのプロジェクト概念
  • 分割ファイル管理においての関数の扱い

といった点にフォーカスされているものはパッと見つからなかったのでTips的に残しておきます。

GASのプロジェクト概念について

GASは、Google Spreadsheet等のGASで扱う実ファイル上からダイレクトに記述することができます。
手軽でいいのですが、この簡易さがプロジェクト概念を少しわかりづらいものにしているような気がします。
Google Spreadsheet等実ファイルからスクリプトエディタを起動した際に表示されるWeb Editor画面です。

f:id:itaoyuta:20170908234932p:plain

実ファイルからスクリプトエデェタを起動した際に作られるのは、GASファイルではなくGASプロジェクトなんですね。
初めて触った時、この概念について一瞬混乱しました(笑
よく見ると、「無題のプロジェクト」って書いてありますしね…

GASのプロジェクト管理について

CINRAではGASの再開発を避けるため、1プロジェクトにファイルを集約させています。
そこで問題となるのが、関数及び変数名の重複です。
1プロジェクトで宣言された関数及び変数は、スクリプトファイルを跨いでもユニークなものでなくてはなりません。
例えばa.jsでfunction hoge(){}とb.jsでfunction hoge(){}がある場合、hoge()をコールしてもどちらかしかコールされないということです。

関数及び変数名の重複を防ぐために

単純な規則なのですが、分割したスクリプト内は全てモジュールとして管理します。
分割されたスクリプトファイル名を素にしたオブジェクト名でラップしプロパティで管理することで、関数及び変数名の重複を防いでいます。

spreadsheet.js

f:id:itaoyuta:20170909000430p:plain

ファイルの関数呼び出し問題

spreadsheetLib.getSheetName()のように各所からよびだそうと考えていたのですが、全く呼び出せずハマりました。
色々試したところ、GASは「グローバルオブジェクトに関数宣言文で関数を定義する」が基本設計のようです。
つまり function spreadsheetLib_getSheetName(){} のような形のみ受け付けるような感じです。
なので、基本実装はmoduleで開発(spreadsheetLib.getSheetName())で、外部APIとして呼び出される想定のものは、ピリオドをアンダースコアに置き換えて対応するようにすることにしています。

f:id:itaoyuta:20170909080922p:plain


CINRAでの活動について

ついでですが、CINRAでのGAS開発自体は以下の構成でやっています。

Execution APIは本当に便利でいいですね。
フロントエンドで終わるような案件で、文言変更が過剰に多いパターンや、複数言語展開が必要なパターンなどはGoogle Spreadsheet上でディレクターに管理してもらって、あとはそのSpreadsheetをjsonにコンバートしてそのままフロントhtmlに挿入するような構成で実装しています。Spreadsheetを簡易DBのように扱うような感覚ですね。
この構成を取ることで、エンジニアとディレクター工数を大幅に削減することができるのでおすすめです。

Google Spreadsheetでの記述例

f:id:itaoyuta:20170909085614p:plain

*1:Google apps scriptの略称