Git

これまで、bobuhiro11.net と blog.bobuhiro11.net は、 自分で管理するサーバから配信していた。 ただ、どちらも静的サイトなので、必ずしも自分でインフラを管理する必要はなく、 楽をするために、これからはGithub Pagesを使って配信することにした。 調べてみたところ、Github Pagesでは、独自ドメインは利用できるが、HTTPSで配信することができない。 そこで、Github Pagesの前段に、SSL終端のできるCDNを配置した。 SSL終端のできるCDNは、いくつかあるようだが、 今回は無料で利用できるCloudflareを選択した。 Cloudflareには、DNSの機能もあるので、 お名前.comで登録している bobuhiro11.net とそのサブドメインを Cloudflareへ移行した。 まとめると、以下のようになる。 お名前.com：ドメインのレジストリ Cloudflare：DNSとCDN（SSL終端） Github Pages：静的サイトのビルドとHTTP配信 Githubの設定 2つのPrivateリポジトリを作成して、jekyllのコードをpush リポジトリの公開範囲がprivateであっても、gh-pagesブランチの内容は自動的に公開 リポジトリ直下に、ドメイン名を記述したCNAMEを配置 SettingsタブのGithub Pagesで確認 jekyllコードは自動でビルド Cloudflareの設定 ふつうzone apexにCNAMEレコードはマッピングできないが、 Cloudflareでは、CNAME Flatteningによって、例外的に割り当てることができる。 Aレコードよりも管理が楽なので、zone apexにもCNAMEを割り当てた。 適当にアカウントを登録して、設定を入れていく。 CloudflareとGithub Pagesの間では、sslを利用できないので、CryptoタブのSSL設定はFlexibleとした。 また、ブラウザにhttps接続を強制するために、HSTS（HTTP Strict Transport Security）の設定をする。 DNSタブ Type:CNAME, Name:blog, Value:bobuhiro11.github.io, TTL: Automatic, Status: DNS and HTTP proxy(CDN) Type:CNAME, Name:bobuhiro11.net, Value:bobuhiro11.github.io, TTL: Automatic, Status: DNS and HTTP proxy(CDN) Type:MX, Name:bobuhiro11.net, Value:xxxx, TTL: Automatic Type:TXT, Name:bobuhiro11.net, Value:xxxx, TTL: Automatic NSを2つ割り当ててくれるので、メモしておく（お名前.comの設定で使う） Cryptoタブ SSL: Flexible Always use HTTPS: On HSTS: Status: On, Max-Age: 6 months ,Include subdomains: On ,Preload: On ,No-sniff: On Automatic HTTPS Rewrites: On お名前.comの設定 DNSサーバを、Cloudflareのところでメモした*.ns.cloudflare.comに変更する お名前.comが管理しているDNSサーバ*.dnsv.jpのDNSレコードは削除しておく 設定情報の確認 しばらく待ってから、設定が正しく入っているかを確認 ...

GithubやBitbucketで管理している プライベートリポジトリに対して、 CI（継続的インテグレーション） とCD（継続的デリバリー）を実現する。 ここでは、werckerを使って、 テストとデプロイを自動化する方法をメモしておく。 werckerは、GithubとBitbucketどちらのプライベートリポジトリにも対応しており、 今のところ無料で利用できる。 デプロイ先はherokuとした。 herokuは、基本的に無料で、手軽にPaaS環境を利用できる。 ただし、無料枠での利用においては、 30分間アクセスがないとスリープ状態になったり、 稼働時間を月1,000時間に制限されたりするので注意する。 想定するアプリケーションは、Python3とFlask（Python向けウェブアプリケーションフレームワーク）で実装されたウェブサービスとする。 まず、リポジトリに3つの設定ファイル（wercker.yml、Procfile、runtime.txt）を追加する。 wercker.ymlは、werckerで利用する設定ファイルで、 大きく分けてbuildとdeployという2つのセクションから構成される。 buildセクションには、依存ライブラリのインストールと、ユニットテストの実行について記述する。 一方、deployセクションには、 herokuへのデプロイ時に参照するSSHキーペアの名前（key-name: HEROKU）を指定する。 HEROKUという名のSSHキーペアの作成手順は、後述する。 また、最新版のheroku CLIを利用するために、 install-toolbelt: true と記述しておく。 Procfileには、アプリケーション名: コマンドの記法で、起動コマンドを記述する。 さらに、runtime.txtでPythonのバージョンを指定する。 特に指定がなかった場合には、Python 2系がインストールされるので注意する。 # wercker.yml box: python services: build: steps: - script: name: install dependencies code: | pip3 install -r requirements.txt - script: name: test code: | python3 -m unittest discover -v && flake8 . deploy: steps: - heroku-deploy: install-toolbelt: true key-name: HEROKU # Procfile web: python -m web.main # runtime.txt python-3.6.1 続いて、werckerのウェブUIで、wercker・リポジトリ間の紐づけと、CIにおけるパイプラインを設定する。 werckerのユーザ登録後、アプリケーションをdashboardから追加し、リポジトリと紐付ける。 アプリケーションの追加後、Workflowsタブを選択し、Add new pipelineからdeployを追加する。 さらに、masterブランチへのPUSHのタイミングで、 buildとdeployが連続して動作するように、ウェブUI上でbuildの直後にdeployをつなげる。 また、deployの実行中にherokuへログインするために、 EnvironmentタブのGenerate SSH Keysボタンから、SSHキーペアを生成し、 環境変数（HEROKU_PRIVATEとHEROKU_PUBLIC）として格納する。 加えて、Environmentタブから、 herokuのアプリケーション名を指示する環境変数 （変数名はHEROKU_APP_NAME、値はherokuのアプリケーション名）を登録する。 ...