投稿

2017の投稿を表示しています

指定された国のタイムゾーン情報をどうやって設定すれば良いか調べる方法

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

社内でガチの初心者向けDocker勉強会をしました

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

オライリーのDocker本を読んだり色々な記事を読んだりしたので自分なりにまとめる(Dockerfileについて)

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レコードを設定できな

基本的な使い方を学ぶために速習Docker的なことをしました

イメージ
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

AWSを使ってソーリーサーバを構築しました。割と便利だと思う…。

イメージ
とてもお久しぶりです。 恵比寿の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 ディレクティブのかたまりを、ソーリーページの