Reach Over The Sky, Tear The Sky

海外向けサービスを構築したときのお話です。 たとえば突然「インドネシア向けサービスを作りたいんだけどさ」みたいなことを言われたとします。 専用サーバを構築するとして、そのサーバの時刻をその国のタイムゾーンで合わせないといけないわけです。 どうやって合わせる…？ていうか時差は何時間？ まずその国の「アルファベット２文字の国コード」を確認します。 例えば このWikipediaのページ で確認できます。 日本なら、「JP」ですね。インドネシアは「ID」です。 次に、 このWikipediaのページ を開いて、その２文字の国コードの行を検索します。 「CC」の列が「ID」の行です。 4つありますね。 これにより、インドネシアにはタイムゾーンが4種類あり、GMT+07:00、GMT+08:00、GMT+09:00の３種類があるわけです。 なので、エンジニアとしては「調べたところ、インドネシアは時差が４種類ほどあるようなのですが、どれにすれば良いでしょうか？」みたいなことを言って確認する必要が出てくるわけです。 以上、簡単ですが、何気に重要なタイムゾーンの選定方法でした。

その時のスライドがこちらです。 Docker study for beginner in My Company 2017/10/19 from Masumi Yoshida 勉強会当日には、主に「Dockerを一ミリも使ったことがないエンジニア」に集まっていただき、Dockerってどんな感じのソフトウェア・システムなのか、自社ではどんな感じで開発に利用してるのかというような観点でお話しました。 デザイナーも来てくれたりしたので、具体的な操作方法は抜きにしてとにかく概要を理解してもらうことに重点を置いたスライドになりました。 本当はハンズオンのパートを作る時間を捻出できなかっただけですが…。 社内では割と好評だったので（そもそも勉強会をオラッっとやる人が少ない…）、次回はECSについて説明するようなスライドを作成できればと考えています。

Docker経験値0だった私も何冊か本を読んで実際にDockerfileを見たりいじったりしてみてECSに試行錯誤でデプロイしてみたりして、ようやく少しずつ慣れてきた感が出てきました。 しかしまだまだ「バッチリできます！」というには力不足間は否めなく…いやそういう話じゃない。 折角本を読んだりネット上の先輩たちの記事を読んだりして色々覚えたのだから、それをまとめておきたいと思います。 実はもうすでに 日本語での公式なDockerfileベストプラクティス が存在するので、意味がないといえばたぶん意味はないのですが、アウトプットをして学習にいったんの区切りをつけるという意味で自己満足も兼ねて書きたいと思います。 Dockerfileについての基本的なこと 1コンテナ1プロセスを起動するつもりでDockerfileを書く 1プロセスとはつまりnginxとmod-phpによるPHPアプリケーションなら2つのコンテナを用意するということ コマンドは大文字で書く（ RUN, COPY, EXPOSE 等） #によるコメントアウトが使える FROM 文は先頭に1行だけ書く CMD 文は末尾に1行だけ書く Dockerfile についてやるべきこと・意識すべきこと DockerHub のイメージは「公式」とわかるもの以外むやみやたらに使わずできるだけ Dockerfile を読んでから利用を判断する DockerHub は Docker イメージの共有サイトだが、有象無象のコンテナイメージが登録されており、（その意図はなくても）セキュリティ的に危険なコンテナが存在する可能性は十分にある。  DockerHubが公式に提供しているNginx  など、ソフトウェアベンダ（団体）の公式イメージ以外は基本的に利用しないことで基本的なセキュリティある程度確保することができる。 構文にはshell形式とexec形式が利用できるものがあるが基本的にexec形式を利用する 例えばCMDコマンドはshell形式とexec形式を利用することができる。 shell形式は指定された文字列を /bin/sh -c に渡すことでコマンドを実行する。 その場合に、exec形式だと/bin/shに対する攻撃のような文字列の実行を回避することができる。

日本語.jp みたいなドメインってたまに見かけますが実際に自分が運用することになるとは思わなかったので学んだことをまとめたいと思います。 このような形式のドメイン名は「 国際化ドメイン名 」と呼ばれるものらしいです。 従来のアルファベット、数字、ハイフン以外にマルチバイト文字を利用できるようにする仕組みのことで、日本語の他にもアラビア文字なども利用できるようです。 ただ、毎回国際化ドメインと呼ぶのもアレだし非エンジニアのスタッフに説明する時に相手に難しそうなイメージを持たれたくないので、 日本語が含まれたドメイン名のことを日本語ドメインと会社では呼んでいます。 中国語だったら中国語ドメインですね。 この日本語ドメインをDNSサーバが理解できるようにするためには、 Punycode（ピュニコード） と呼ばれる形式で、アルファベット数字ハイフンだけの、既存のドメイン名に使用できる文字だけの対応ドメインに変換してあげる必要があります。 言いたかったのはそれだけです。 たとえば、JPRSが運用している 日本語.jp はPunycodeだと xn--wgv71a119e.jp になります。 これはHTTPS接続についてほんのちょっとだけめんどくさいトラブルが発生します。 curlなどでHTTPアクセスのテストをすることはよくあると思いますが、開発している日本語ドメインのサービスがHTTPSを基本としていて、curlでもHTTPSで行う場合、通常はSSLに関するエラーが出力されます。 SSL証明書を取得するときはPunycode変換済みのドメイン名で取得することが前提となっており、変換済みのドメインは変換前のドメインとリテラル的に同等とみなされないからです。 SSL証明書エラーを回避するには curlの -k オプションを利用します。 今回私が運用することになった日本語のドメイン名は、AWSのACMで無料の証明書を取得しました。 そのドメインは お名前.com で購入したのですが、デフォルトの状態では取得不可能でした。 なぜか？それは、 こちらの仕様 によるもの 日本語ドメインは、A / AAAA / CNAMEレコードのみご利用いただくことが可能です。 設定方法はこちらをご参照ください。 これはMXレコードを設定できな

MacでDockerを使うために基本的な使い方を学習しました。 下記を読みながら、適宜読み替えたりググったりしてコマンドを実行してみました。 Dockerエキスパート養成読本［活用の基礎と実践ノウハウ満載！］ (Software Design plus) Docker実行環境の構築 brew install docker brew install docker-machine brew install docker-compose Dockerマシンを作成しようとして失敗 TearTheSky-MacBook:~ TearTheSky$ docker-machine create --driver virtualbox test-docker Running pre-create checks... (test-docker) You are using version 4.3.26r98988 of VirtualBox. If you encounter issues, you might want to upgrade to version 5 at  https://www.virtualbox.org Error with pre-create check: "VirtualBox is configured with multiple host-only adapters with the same IP \"192.168.33.1\". Please remove one." TearTheSky-MacBook:~ TearTheSky$ 対処方法はこちら  http://qiita.com/niiyz/items/70580164551c710a75d3 VirtualBox上のDockerマシンの確認 TearTheSky-MacBook:~ TearTheSky$ docker-machine ls NAME          ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER        ERRORS test-docker

とてもお久しぶりです。 恵比寿のITベンチャーでサービス運営やっています。 仲間募集中です。ご興味ある方はTwitterなどでご連絡ください。 今回はAWSを使って、わりと便利なソーリーサーバを構築しましたというお話です。 構成は下の図のようになっています。 通信フローとしては、まずエンドユーザがELBにアクセスします。 このELBは既存のWebサービスやWebサイトをバランシングしていたものです。 諸事情によりメンテナンスしたり、ドメインを畳むことになったという話を想定しています。 そのELBに接続されていたWebサーバやアプリケーションサーバの代わりにソーリーサーバを接続します。 するとエンドユーザはソーリーサーバにアクセスしてきますよね。 ソーリーサーバはリクエストを受けたら、各ドメインに対応させたいCloudFrontへリクエストをパスします。 CloudFrontはS3のコンテンツを返すのですが、このS3に静的なソーリーページを格納しておきます。 それにより、ドメインにアクセスしてきたエンドユーザにソーリーページを見せることができます。 ポイントはソーリーサーバとCloudFrontですがやってることは簡単です。 まず、ソーリーサーバはただのNginxです。 proxy_pass を使って、特定ドメインに来たリクエストを対応するCloudFrontのドメインへパスします。 その設定は、/etc/nginx/conf.d/virtual.conf に書きました。 server {          listen 80;         server_name example.com;         if ($http_x_forwarded_proto != https) {                  return 301 https://$host$request_uri;          }         location / {                  proxy_pass  http://domain-a.sorry.example.com/ ;          } } 上記の server ディレクティブのかたまりを、ソーリーページの