Barcelonaチュートリアル1(ローカルDBでまず使ってみる編)
Tweet
はじめに
この記事は、Barcelonaを紹介するシリーズの一つです。
- Kubernetes VS Barcelona
- Barcelonaのアーキテクチャ
- Barcelonaチュートリアル1 (この記事)
- Barcelonaチュートリアル2（運用編）
- Barcelonaチュートリアル3（AWSにインストール）
- Barcelonaチュートリアル4 (Mastodonを動かす)
- Barcelonaの今後
必要なもの
このチュートリアルでは、BarcelonaのAPIサービスをローカルで動かして、CloudFormationとの連携部分だけ、実際のAWS上で動かします。つまり、下記の図の左半分をローカルの docker-compose で動かして、右半分をAWS上で動かします。
必要なものは以下の通りです。
- Docker実行環境
- docker-compose
- テスト用 AWS アカウント
- 管理者（全権）IAMアカウント
- アクセスキー
- 1日あたり 1$ 程度の費用
- 管理者（全権）IAMアカウント
- github アカウント
- github グループ
- github トークン
まず、ローカルでは、Docker実行環境と docker-compose が必要になります。
それと、AWSのアカウントが必要になります。多くのリソースを作成するので、本番環境とは別のテスト用アカウントでほ使用したほうがいいと思います。このアカウントの管理者の権限を持った、アクセスキーとシークレットキーが必要になります。
それと、認証に使うので、githubのトークンが必要になります。 https://github.com/settings/tokens/new から、userの権限だけを持ったトークンを作成しておいてください。
準備
barcelona-cliのインストール
下記ページから、最新版をダウンロードして、Pathの通ったディレクトリにコピーしてください。
実行例
$ wget https://github.com/degica/barcelona-cli/releases/download/0.7.0/bcn_darwin_amd64.zip
$ unzip bcn_darwin_amd64.zip
$ cp bcn /usr/local/bin/bcn
$ bcn
NAME:
bcn - Barcelona Command Line Client
USAGE:
bcn [global options] command [command options] [arguments...]
VERSION:
0.7.0
COMMANDS:
login Login Barcelona
deploy Deploy a Barcelona heritage
create Create a new Barcelona heritage
district District operations
endpoint Endpoint operations
env Environment variable operations
run Run command inside Barcelona environment
ssh SSH into Barcelona container instance
release Manipulate releases
notification Operate notification
app Manage heritages
review Review Apps
help, h Shows a list of commands or help for one command
GLOBAL OPTIONS:
--debug, -d Enable debug mode
--help, -h show help
--version, -v print the version
barcelonaのダウンロード
barcelona本体は、リポジトリからcloneして、buildするだけです。ただし、認証用のgithubのグループ名だけは build の前に変更してください。
$ git clone https://github.com/degica/barcelona
$ cd barcelona
$ vi docker-compose.yml # github グループ名の変更
$ docker-compose build
修正するのは、下記の GITHUB_ で始まる3つの環境変数です。
...
environment: &env_base
...
GITHUB_ORGANIZATION: 'degica'
GITHUB_DEVELOPER_TEAM: 'developers'
GITHUB_ADMIN_TEAM: 'Admin developers'
...
ここは、あなたの所属する、github organization と github team の名前に変更してください。GITHUB_DEVELOPER_TEAMとGITHUB_ADMIN_TEAMは同じ team でかまいません。
所属していない場合は、自分で organization と team を作成して、その名前にしてください。
これは、次のように認証に使います。
- ログイン時に github token を
~/.bcn/loginに保存する - CLIは全てのリクエストに保存した github token を付加する
- APIサーバは、リクエストごとに token から、そのユーザのプロフィール情報を入手する
- プロフィールの中で、organizationや team が一致すれば、認証を通す
従って、この token では、リポジトリの参照や変更は一切しません。
Docker API プロセスの開始、ログイン
最初に Barcelona をローカルで使える状態にします。
Docker APIの開始
最初に、以下のように API プロセスを開始します。
$ docker-compose run web bundle install
$ docker-compose run web rake db:create db:schema:load
$ docker-compose up -d
$ docker-compose logs
...
web_1 | => Booting Puma
web_1 | => Rails 5.2.2 application starting in development
web_1 | => Run `rails server -h` for more startup options
web_1 | Puma starting in single mode...
web_1 | * Version 3.12.0 (ruby 2.6.2-p47), codename: Llamas in Pajamas
web_1 | * Min threads: 5, max threads: 5
web_1 | * Environment: development
web_1 | * Listening on tcp://0.0.0.0:3333
web_1 | Use Ctrl-C to stop
...
上記のメッセージが表示されたら、正常に起動しています。 http://localhost:3333/ にアクセスして、Railsのデフォルトルートページが表示されれば成功です。
$ curl http://localhost:3333/
<!DOCTYPE html>
<html>
<head>
<title>Ruby on Rails</title>
....
Barcelonaへのログイン
次に、このローカルで起動した Barcelona にログインします。プロンプトに github token を与えると、以下の処理が行われます。
- token から github のプロフィールを入手して、環境変数に設定した組織名、チーム名と比較して確認する
- token と EndPoint URLを
~/.bcn/loginに保存する - Barcelona用の ssh key pair を作成する
ssh key pairは、bcn sshと bch runで使用するものです。後のチュートリアルで使用します。
実行例
$ bcn login http://localhost:3333/
Create new GitHub access token with read:org permission here https://github.com/settings/tokens/new
GitHub Token: (github token を入力)
Generating your SSH key pair...
Generating public/private ecdsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/tnaka/.bcn/id_ecdsa.
Your public key has been saved in /Users/tnaka/.bcn/id_ecdsa.pub.
The key fingerprint is:
SHA256:kg6edlm3dJLIVDEQjkko3TBpi8krhwz3u/bPKwfxsF4
The key's randomart image is:
+---[ECDSA 521]---+
| .o=. oo+. |
| . =o.+ . . |
| . = .o o |
|. = . o+ . . |
|oo o. o=S = . |
|o.o..+o+Eo + |
| o +o+o . |
| .o.o.. |
| ..o.++. |
+----[SHA256]-----+
Registering your public key...
District の作成
次に、District(仮想PaaS)を作成します。ここからは、AWS上にリソースを作成することになります。
最初に、次のコマンドで、Districtがまだ存在しないことを確認します。
$ bcn district list
NAME | REGION | INSTANCE TYPE | CLUSTER SIZE | AWS ROLE | ACCESS KEY ID
+------+--------+---------------+--------------+----------+---------------+
$
Districtの作成は、bcn district createで行います。このコマンドの help を見てみましょう。
$ bcn district create --help
NAME:
bcn district create - Create a new district
USAGE:
bcn district create [command options] DISTRICT_NAME
OPTIONS:
--region value AWS region (default: "us-east-1")
--nat-type value NAT type (default: "instance")
--cluster-instance-type value Cluster Instance Type (default: "t2.small")
--regionは、AWSリソースを確保するAWSリージョンを指定します。ここは、普段使ってないリージョンにした方が、何が作成されるかわかりやすいと思います。
--nat-typeは、managed_gatewayを指定してください。
--cluster-insntance-typeは、指定しないと、t2.smallのインスタンスを一つだけ作成します。このチュートリアルでは、これで問題ないでしょう。
以上を指定して、コマンドを実行すると、AWS Access Key と Secret Access Key の入力を促すプロンプトが表示されるので、入力してください。Secret Access Key は保存されず、このコマンドの実行が完了した時点で捨てられます。
実行例
$ bcn district create --region=us-west-2 --nat-type=managed_gateway demo1
AWS Access Key ID: AKIAJVDWYHYW4UGDMF2Q
AWS Secret Access Key:
Name: demo1
Region: us-west-2
Cluster Backend: autoscaling
Cluster Instance Type: t2.small
Cluster Size: 1
S3 Bucket Name: barcelona-demo1-1553837746
Stack Name: barcelona-demo1
Stack Status: CREATE_IN_PROGRESS
NAT Type: managed_gateway
CIDR Block: 10.174.0.0/16
AWS Access Key ID: AKxxxxxxxxxxxxxxx
AWS Role:
Container Instances:
Heritages:
Notifications:
Plugins:
すると、上記のような表示の後に、CloudFormation のテンプレートが作成され、そのまま適用されます。
このテンプレートの名前は “barcelona-(District名)” で、AWSのWeb Consoleから見ることができます。
このテンプレートの “Template” タブや “Resources” タブで、どのような AWS リソースが確保されたのか確認することができます。
また、bcn district show というコマンドでも主なリソースを表示することができます。
$ bcn district show demo1
Name: demo1
Region: us-west-2
Cluster Backend: autoscaling
Cluster Instance Type: t2.small
Cluster Size: 1
S3 Bucket Name: barcelona-demo1-nnnnnnnnnnnn
Stack Name: barcelona-demo1
Stack Status: CREATE_COMPLETE
NAT Type: managed_gateway
CIDR Block: 10.nnn.0.0/16
AWS Access Key ID: AKIAJVDWYHYW4UGDMF2Q
AWS Role:
Container Instances:
i-xxxxxxxxxxxxxxx 10.nnn.n.148 ACTIVE
Heritages:
hello
Notifications:
Plugins:
Heritage の作成
次に、この District に Heritage を作成します。
Heritageは、仮想PaaS上で稼働するアプリケーションを表す仮想リソースです。今回は、下記のアプリケーションを動かします。
これは、Ruby の sinatra というフレームワークで作成したアプリケーションで、”Hello world!” を返すだけのサンプルアプリケーションです。docker.io/essa/barcelona-sample-hello に Docker イメージとして公開してあります。この Dockerイメージを、先ほど作成した demo1 という Barcelona の District で動かしてみます。
EndPoint の作成
最初に、EndPoint を作成します。
EndPointは、Heritage をインターネットに公開するための接点となるリソースで、AWS上では ALB に対応します。
$ bcn endpoint create --public --district=demo1 test-endpoint
Name: test-endpoint
Public: true
SSL Policy: intermediate
Certificate ARN:
DNS Name:
barcelona.yml の作成
適当なディレクトリに barcelona.yml というファイルを作成し、下記の内容を入力してください。または、こちらからダウンロードしてください。
environments:
production:
name: hello
image_name: docker.io/essa/barcelona-sample-hello
services:
- name: web
service_type: web
public: true
cpu: 128
memory: 256
command: ruby hello.rb
listeners:
- endpoint: test-endpoint
health_check_interval: 10
health_check_path: /
rule_conditions:
- type: path-pattern
value: '*'
このファイルのあるディレクトリで、下記のコマンドを実行してください。
$ bcn create -e production -d demo1
Name: hello
Image Name: docker.io/essa/barcelona-sample-hello
Image Tag : latest
Version: 2
Before Deploy: None
Token: 9fd04e74-8ee2-4272-a7fa-e169cac87842
Scheduled Tasks:
Environment Variables
bcn createは、カレントディレクトリの barcelona.yml の内容を読み込んで、-eで指定した環境(environments:)に対応する内容で、Heritage を作成します。
これで、hello という名前の Heritage が作成されます。
ここで、次のコマンドを実行すると、アプリケーションが Deploy されます。
$ bcn deploy -e production --tag=latest
この Heritage は listeners という属性を持っていますので、これを使って、先ほど作成した test-endpoint という EndPoint に接続されています。
AWS Web Console の EC2 -> LoadBalancers を見ると、test-endpoint という名前のロードバランサーが作成されているので、その DNSName という属性でアクセスしてみてください。
$ curl test-endpoint-184812406.us-west-2.elb.amazonaws.com
Hello world!
単純な Web アプリであれば、barcelona.ymlの image_name という属性の値を変えれば、同じ手順で本番環境で稼働することができます。
アクセスログと稼働状況の確認
これは、ECSのサービス上で稼働していますので、AWS Web Console の ECS から CPU と Memory の使用状況を確認することができます。
また、CloudWatch Logs には、アプリケーションのログとアクセスログが出力されています。
後始末（リソースの削除）
ここまでに AWS上に確保したリソースは、以下の CloudFormation Stack から作成されています。
- barcelona-demo1
- endpoint-test-endpoint
- heritage-hello
- demo1-hello-web
従って、これらのStack を AWS Web Console から削除すれば、全てのリソースを削除してもとどおりにすることができます。
特に、ロードバランサーと EC2 インスタンスは、稼働時間に応じた費用が発生するので、動作確認が終わったら、必ず削除してください。
まとめ
Barcelonaをローカルで実行し、実際に AWS の ECS や ALB を使った本番環境でサンプルアプリを動かしてみました。
これは、単に EC2 インスタンスを一つ起動し、そこでサンプルプログラムを走らせたのと違って、中身の Docker イメージ（アプリケーション）さえ入れ替えれば、本番環境として十分使える状態であることに注目してください。
- AWS Web Console から、ログや稼働状況を確認できる
- 必要であれば、CloudWatchのアラートを追加して、トラブル時のアラートを上げることができる
- コンテナインスタンスに障害があった場合に、自動的に新しいインスタンスに切り替える
- コンテナ（アプリケーション）に異常があって、異常終了した場合に、自動的に再起動する
- AWS Web Console から多重度を上げたり、インスタンスタイプを変更して、高負荷に耐える運用に切り替えることができる
- 多重度の増減やコンテナインスタンスの変更時に、サービスを継続したままリソースを入れ替える（ローリングアップデート）ことができる
- アプリケーションは、ネットワークレベルで外部から隔絶されたセキュアなプライベートネットワークで動いている
実際に、デジカでは、これと同じ環境で多くのサービスを動かしていて、その環境でPCIDSSの監査に合格しています。
この安全性や負荷耐性を考えると、驚異的に簡単な手順で動かせていると思いますが、いかがでしょうか。