読者です 読者をやめる 読者になる 読者になる

長生村本郷Engineers'Blog

千葉県長生村本郷育ちのエンジニアが書いているブログ

無料で運用! GKE + Kubernetes で Hubot 〜独自ネットワーク作成、設定ファイルから起動編〜

前回手元のMacからコンテナクラスタ → Deployment → LB 作成する手順をまとめました。

kenzo0107.hatenablog.com

但し、8080ポートがフルオープンとなってしまい、誰でもアクセスが可能であるという、
セキュリティ的に非常によろしくない状態でした。

その為、今回は以下実施します。

前回の独自ネットワーク設定していないクラスタは削除して問題ないです。お任せします m(_ _)m

前回同様の Git Repository 用意

$ git clone https://github.com/kenzo0107/hubot-slack-on-docker
$ cd hubot-slack-on-docker

Network 作成

  • hubot-network というネットワークを作成します。
macOS%$ gcloud compute networks create hubot-network

ファイアウォール作成

  • 作成したネットワークに特定 IP からのみ 8080 ポートアクセス許可
macOS%$ gcloud compute firewall-rules create hubot-rule --network hubot-network --allow tcp:8080 --source-ranges xxx.xxx.xxx.xxx,yyy.yyy.yyy.yyy.yyy

Container Clusters 作成

macOS%$ gcloud container clusters create hubot-cluster-free \
      --machine-type f1-micro \
      --disk-size=30 \
      --num-nodes=3 \
      --network=hubot-network \
      --cluster-ipv4-cidr=10.0.0.0/14

例) –cluster-ipv4-cidr=10.0.0.0/8 指定した場合のエラー

ERROR: (gcloud.container.clusters.create) ResponseError: code=400, message=cluster.cluster_ipv4_cidr CIDR block size must be no bigger than /9 and no smaller than /19, found /8.

ノード数を 1 に変更

macOS%$ gcloud container clusters resize hubot-cluster-free --size=1

Deployment 作成

macOS%$ kubectl create -f gke-deployment.yml

Deployment, Replicaset, Pod 一覧表示

  • ラベル付けした app: hubot を条件指定
macOS%$ kubectl get deployments,replicasets,pods --selector app=hubot

フォーマットを yaml 形式で出力

macOS%$ kubectl get deployment deployment-hubot -o yaml

サービス公開する為、LoadBalancer 付加

macOS%$ kubectl create -f gke-lb.yml

サービス一覧表示

macOS%$ kubectl get svc
NAME           CLUSTER-IP     EXTERNAL-IP     PORT(S)          AGE
kubernetes     10.3.240.1     <none>          443/TCP          20m
loadbalancer   10.3.241.129   zz.zzz.zzz.zzz   8080:31628/TCP   4m

※EXTERNAL-IP : zz.zzz.zzz.zzzグローバルIP

いざ、テスト !

macOS%$ curl \
-X POST \
-H "Content-Type: application/json" \
-d \
'{
 "webhookEvent":"jira:issue_updated",
 "comment":{
   "author":{
     "name":"himuko"
    },
    "body":"[~kenzo.tanaka] 東京03 秋山 ケンコバ 劇団ひとり"
 },
 "issue": {
   "key":"key",
   "fields":{
     "summary":"summary"
    }
  }
}' \
http://zz.zzz.zzz.zzz:8080/hubot/jira-comment-dm
  • できた! f:id:kenzo0107:20170516220548p:plain

後片付け

  • Deployment 削除
macOS%$ kubectl delete -f gke-deployment.yml
  • LoadBalancer 削除
macOS%$ kubectl delete -f gke-lb.yml

総評

ネットワークのファイアウォール設定してコンテナ起動したが動かなかった所、かなり詰まりました (; ~_~)
Stackoverflow にたまたま同様のイシューをあげている方がおり参考にさせて頂きました。
助かった汗

これから Nginx + Rails 等、よくありそうなケースで GKE + Kubernetes を試して運用してみたいと思います。
まとまったらまた追記します!

参考

Unable to launch a GKE (Google Container Engine) cluster with a custom network

無料で運用! GKE + Kubernetes で Hubot 〜CLIから実行編〜

Imgur

概要

  • 無料枠を使って Slack 連携する Hubot を GKE で構築します。
  • おまけで JIRA 連携も

Google Cloud SDK のインストール方法と初期化

Mac OS X 用クイックスタート を参照して SDK をダウンロードします。

macOS%$ uname -m

x86_64

kubectl のインストー

macOS%$ gcloud components update kubectl

gcloud デフォルト設定

以下は作成したプロジェクト、リージョン、ゾーンを設定してます。
今後 gcloud コマンド実行時に region 指定等しなくて良くなります。

  • 作成したプロジェクトID : hubot-167007
  • us-west 利用で無料枠を使う為に US リージョンに設定してます。
macOS%$ gcloud auth login
macOS%$ gcloud config set project hubot-167007
macOS%$ gcloud config set compute/region us-west1
macOS%$ gcloud config set compute/zone us-west1-b

Google Cloud Platform の無料階層 参照してください。

クラスタ作成

  • 無料枠を利用するべく f1-micro で 30GB 設定
  • でも作成時は 3 ノード必須
  • 作成完了後、リサイズで 1 ノードに
macOS%$ gcloud container clusters create hubot-cluster-free \
      --machine-type f1-micro \
      --disk-size=30 \
      --num-nodes=3

Creating cluster hubot-cluster-free...done.
Created [https://container.googleapis.com/v1/projects/hubot-167007/zones/us-west1-b/clusters/hubot-cluster-free].
kubeconfig entry generated for hubot-cluster-free.
NAME                ZONE        MASTER_VERSION  MASTER_IP       MACHINE_TYPE  NODE_VERSION  NUM_NODES  STATUS
hubot-cluster-free  us-west1-b  1.5.7           35.xxx.xxx.xxx  f1-micro      1.5.7         3          RUNNING
  • コンソールを見ると作成中であることが確認できます。

Imgur

  • 以下コマンドで確認可
macOS% $ kubectl get nodes 
NAME                                                STATUS    AGE       VERSION
gke-hubot-cluster-free-default-pool-a3b110d2-9k6s   Ready     59s       v1.5.7
gke-hubot-cluster-free-default-pool-a3b110d2-lqxg   Ready     1m        v1.5.7
gke-hubot-cluster-free-default-pool-a3b110d2-xqs8   Ready     1m        v1.5.7
  • 1 ノードにリサイズ
macOS%$ gcloud container clusters resize hubot-cluster-free --size=1

Pool [default-pool] for [hubot-cluster-free] will be resized to 1.

Do you want to continue (Y/n)?  y

Resizing hubot-cluster-free...done.
Updated [https://container.googleapis.com/v1/projects/hubot-167007/zones/us-west1-b/clusters/hubot-cluster-free].

Imgur

リサイズできるなら初めから 1 ノードで作らせて欲しい (>_<)

コンソール上だとやっぱりダメ (T_T)

Imgur

認証情報 取得

  • コンテナクラスタの認証情報を取得し、kubectlを利用してコンテナ クラスタ上にコンテナを作成できるようになります。
macOS%$ gcloud container clusters get-credentials hubot-cluster-free

Fetching cluster endpoint and auth data.
kubeconfig entry generated for hubot-cluster-free.
macOS%$ gcloud container clusters describe hubot-cluster-free

ローカルの Docker 起動

macOS%$ git clone https://github.com/kenzo0107/hubot-slack-on-docker
macOS%$ cd hubot-slack-on-docker
macOS%$ docker-compose up -d
macOS%$ docker ps

CONTAINER ID        IMAGE                      COMMAND                  CREATED             STATUS              PORTS                              NAMES
12f77feb09b4        hubotslackondocker_hubot   "/bin/sh -c 'bash ..."   24 minutes ago      Up 24 minutes       6379/tcp, 0.0.0.0:8080->8080/tcp   hubotslackondocker_hubot_1

Hubot 動作確認

Slack上に Hubot が登場していて hello と呼びかけると Hi と返してくれたら成功です。

f:id:kenzo0107:20170510012328p:plain

CONTAINER ID から イメージをcommit

macOS%$ docker commit 12f77feb09b4 gcr.io/hubot-167007/hubot:latest

macOS%$ docker images 
REPOSITORY                       TAG                 IMAGE ID            CREATED             SIZE
gcr.io/hubot-167007/hubot        latest              2f7336b3a3ce        3 seconds ago       484 MB

gke registory に push

参考: Container Registry への push

macOS%$ gcloud docker -- push gcr.io/hubot-167007/hubot:latest

The push refers to a repository [gcr.io/hubot-167007/hubot]
0569b419082b: Pushed
a7637cfcdfba: Pushed
9f0bdbb7b1fa: Pushed
f1d85eafc75a: Pushed
c2c2b58591f2: Pushed
51c94eacef50: Pushed
69e7fcf7ba41: Pushed
293d09ca6a9d: Pushed
247e72dfcaf5: Pushed
8c2bc9bf1f19: Pushed
40907ce0d959: Pushed
bfba578a7fbe: Pushed
561cbcaac156: Pushed
293a1e72e88b: Pushed
ae09eb3da3dc: Pushed
c06c14d7f919: Pushed
e14577d2cac5: Layer already exists
e8829d5bbd2c: Layer already exists
674ce3c5d814: Layer already exists
308b39a73046: Layer already exists
638903ee8579: Layer already exists

latest: digest: sha256:0c3b29d18b64c1f8ecc1a1bf67462c84d5915a4a708fe87df714d09198eb5fa1 size: 4704
  • latest が被ると過去のイメージのタグが奪われます。容量の無駄になるので削除しましょう。

Imgur

Deployments 作成

macOS%$ kubectl run pod-hubot \
      --image=gcr.io/hubot-167007/hubot:latest \
      --env="HUBOT_SLACK_TOKEN=xoxb-xxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx" \
      --env="HUBOT_SLACK_TEAM=xxxxxx.slack.com" \
      --env="HUBOT_SLACK_BOTNAME=hubot" \
      --env="HUBOT_JIRA_URL=https://<jira_server_domain_or_ip>" \
      --port=8080 \
      --restart='Always'

deployment "pod-hubot" created
  • deployments 状態確認
macOS%$ kubectl get deployments
NAME        DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
pod-hubot   1         1         1            0           10s
  • Pod 状態確認
macOS%$ kubectl get pods

NAME                         READY     STATUS             RESTARTS   AGE
pod-hubot-1713414922-b2dkq   0/1       ImagePullBackOff   0          23s
  • Pod にログイン
$ kubectl exec -it pod-hubot-1713414922-b2dkq /bin/bash
  • service の状態確認
macOS%$ kubectl get service


NAME         CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
kubernetes   10.23.240.1   <none>        443/TCP   22m

EXTERNAL-IP: <none> … 外部へ開いているIPがない。という状態
Private IP は付与されたが Public IP がない、外部のネットワークからアクセスできない状態です。

コンテナ公開

  • Service にロードバランサ付与し公開
macOS%$ kubectl expose deployment pod-hubot --type="LoadBalancer"
service "pod-hubot" exposed
  • Service 確認

EXTERNAL-IP: <pending> となっており、作成途中であることがわかります。

macOS%$ kubectl get service

NAME         CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
kubernetes   10.23.240.1     <none>        443/TCP          25m
pod-hubot    10.23.244.214   <pending>     8080:30453/TCP   8s
  • 再度 Service 確認

無事付与されているのがわかりました。

macOS%$ kubectl get service
NAME         CLUSTER-IP      EXTERNAL-IP     PORT(S)          AGE
kubernetes   10.23.240.1     <none>          443/TCP          27m
pod-hubot    10.23.244.214   104.xxx.x.xxx   8080:30453/TCP   1m

テスト

macOS%$ curl \
-X POST \
-H "Content-Type: application/json" \
-d \
'{
 "webhookEvent":"jira:issue_updated",
 "comment":{
   "author":{
     "name":"himuko"
    },
    "body":"[~kenzo.tanaka] 東京03 秋山 ケンコバ 劇団ひとり"
 },
 "issue": {
   "key":"key",
   "fields":{
     "summary":"summary"
    }
  }
}' \
http://104.xxx.x.xxx:8080/hubot/jira-comment-dm

Imgur

後始末

無料枠だから「別に。。」ですが、掃除しときたい場合に以下実行してください。

  • service 削除
macOS%$ kubectl delete service pod-hubot
service "pod-hubot" deleted
  • pod 削除
macOS%$ kubectl delete pod pod-hubot-729436916-htw3r
service "pod-hubot" deleted
  • deployments 削除
macOS%$ kubectl delete deployments pod-hubot
  • container clusters 削除
    container cluster を削除すれば紐付く deployments, service, pod も削除されます。
macOS%$ gcloud container clusters delete hubot-cluster-free

以上です。

総評

GKEは概念が多く、一概に deployment, pod, service, kubernetes 等覚えることが多いですが
動かしつつ学ぶのは楽しいです。

ほぼ手元の Mac で設定できました!
手元で済むから macOS%$ は不要だった。。

今回作成した service だと外部に 8080 ポート全開です。

次回はアクセス元を制限したポートアクセスやコンテナのアップデートについてまとめます。

kenzo0107.hatenablog.com

Raspberry PI3 Model B に docker-compose で Nginx で認証かけて Prometheus + Node Exporter + Grafana + cAdvisor構築

f:id:kenzo0107:20170430235153p:plain

概要

Raspi3に docker-compose で Prometheus による監視機構を作成しました。

github.com

環境

  • Raspberry Pi 3 Model B (Raspbian GNU/Linux 8) arm7l
  • Docker version 17.04.0-ce, build 4845c56
  • docker-compose version 1.9.0, build 2585387

Raspi に docker インストール

raspi%$ wget -qO- https://get.docker.com/ | sh
raspi%$ sudo usermod -aG docker pi
raspi%$ sudo gpasswd -a $USER docker

Raspi に docker-compose インストール

raspi%$ sudo apt-get update
raspi%$ sudo apt-get install -y apt-transport-https
raspi%$ echo "deb https://packagecloud.io/Hypriot/Schatzkiste/debian/ jessie main" | raspi%sudo tee /etc/apt/sources.list.d/hypriot.list
raspi%$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 37BBEE3F7AD95B3F
raspi%$ sudo apt-get update
raspi%$ sudo apt-get install docker-compose
  • version 確認
raspi%$ docker-compose --version
docker-compose version 1.9.0, build 2585387

docker-compose のプロジェクト設定

raspi%$ cd ~
raspi%$ git clone https://github.com/kenzo0107/vagrant-docker
raspi%$ cd vagrant-docker/docker/prometheus-grafana-on-raspi3

Nginx Basic 認証設定

.htpasswd 作成時のユーザ/パス == GF_SECURITY_ADMIN_USER/GF_SECURITY_ADMIN_PASSWORD  

である必要があります。

Grafana の認証機能により設定した Basic 認証でログインできる仕組みがあり、
一致しない場合、ログインできず、失敗します。

  • grafana/env
GF_SECURITY_ADMIN_USER=admin-user
GF_SECURITY_ADMIN_PASSWORD=admin-pass
  • .htpasswd
raspi%$ htpasswd -c nginx/conf/conf.d/.htpasswd admin-user
New password: (「admin-pass」と入力しEnter)
Re-type new password: (「admin-pass」と入力しEnter)
Adding password for user admin-user

raspi%$ cat nginx/conf/conf.d/.htpasswd
admin-user:$apr1$JLxC83lt$uO7aEn9Z59fZtba4EA7C6/

Cron設定

Raspi の温度や電圧を定期取得し Prometheus に読み込ませるファイル(*.prom)作成します。

*/5 * * * * <home/to/path>/vagrant-docker/docker/prometheus-grafana-on-raspi3/node-exporter/collector/raspi.sh

docker-compose により Docker 起動

raspi%$ docker-compose up -d

Grafana にアクセスしてみる

http://<your_server_ip>:13000 にアクセスすると .htpasswd で指定したユーザ/パスを求められるので入力します f:id:kenzo0107:20170430235949p:plain

その後、Grafana のページが表示されれば成功です。

f:id:kenzo0107:20170501002430p:plain

「Add data Source」をクリックします。

Data Source 設定

以下の様に設定し「Save & Test」をクリックししSuccessすることを確認します。

f:id:kenzo0107:20170501002606p:plain

Dashboard.json インポート

左上のアイコンから Dashboards > Import 選択し DockerDashboard.json をインポートします。

f:id:kenzo0107:20170501003915p:plain

Dashboard 表示

f:id:kenzo0107:20170501003051p:plain

ポイント !

セキュリティ上の観点から外から直接 Grafana を参照させない様にしました。

nginx/conf/conf.d/default.conf

server {
    listen       80;

    location / {
        auth_basic "Restricted";
        auth_basic_user_file /etc/nginx/conf.d/.htpasswd;

        proxy_pass                          http://grafana:3000/;
    }
}

image 選びは慎重に。

以下の点で非常にハマりました。

  1. Raspberry Pi3 Model B (今回はarm7l)上で動作するか
  2. Nginx で Proxy 機能が正しく動作するか

nginx のproxy機能で grafana に繋げても 以下の様に表示されてしまうケースにぶつかりまくりました。

{{alert.title}}

総評

イメージ探しについ時間取ってしまいましたが
自作した方が早かったかもと反省。

今回は自身を監視するという仕組みにしましたが外部から監視し相互に監視し合う体制が必要です。
家庭内稟議が通ればもう一台getしよう!

そして、家庭の為になるものを作ろう!

参考

こちらの本、 Docker について基本的な運用上の設定や概念を理解するには非常によかったです♪

WEB+DB PRESS Vol.98

WEB+DB PRESS Vol.98

peco 小技シリーズ 〜多段ssh + peco, ghq + peco + atom〜

f:id:kenzo0107:20170427172718j:plain

概要

本当に小技です。
が、割と使ってみると作業時間の短縮となって便利という声を頂き
peco 関連でよく使うものを記事にしました。

peco インストール

macOS %$ brew install peco

ssh ログインする Host を検索して選択

前提条件として ~/.ssh/config で接続ホストを管理しています。

gist.github.com

上記を ~/.bashrc などに貼り付けて source ~/.bashrc すれば使えます♪

macOS %$ git clone https://gist.github.com/kenzo0107/06b3b1e202f36b70815cfe0207292a66
macOS %$ cd 06b3b1e202f36b70815cfe0207292a66
macOS %$ cat peco-sshconfig-ssh.sh >> ~/.bashrc
macOS %$ source ~/.bashrc

// sshc 実行!
macOS %$ sshc

上記の様に順調に進むと候補がリストされます。
モザイクしかなくすいません (>_<)
f:id:kenzo0107:20170427171121p:plain

ghq で管理している repository を検索して選択し atom で開く

gist.github.com

こちらも同様、

macOS %$ git clone https://gist.github.com/kenzo0107/e460e31ae2478341cc7a39859ad7fefd
macOS %$ cd e460e31ae2478341cc7a39859ad7fefd
macOS %$ cat peco-git-atom.sh >> ~/.bashrc
macOS %$ source ~/.bashrc

// opg 実行!
macOS %$ opg

f:id:kenzo0107:20170427171728p:plain

他にも様々な箇所で peco を利用させて頂いてます。
こんな peco の使い所あるよーという方、是非教えてください♪

参照

zsh ですが dotfile をまとめてます。

GitHub - kenzo0107/dotfiles: dotfile setting

docker-compose で開発環境構築 〜Nginx アクセスログ(ltsv) を fluentd + elasticsearch + kibana で可視化〜

概要

前回構築した Vagrant 環境上で docker-compose による開発環境構築をします。

kenzo0107.hatenablog.com

今回は前回の続きで Nginx のアクセスログを Elasticsearch + Fluentd + Kibana で可視化してみます。
アプリ

簡単構築手順

macOS% $ git clone https://github.com/kenzo0107/vagrant-docker
macOS% $ cd vagrant-docker
macOS% $ vagrant up
macOS% $ vagrant ssh
vagrant% $ cd /vagrant/nginx-efk

// -d デタッチモードでないのは各コンテナの起動状況がログで見える為です。
vagrant% $ docker-compose up
...
...

docker-compose 構成

Git にまとめています。
https://github.com/kenzo0107/vagrant-docker/tree/master/docker/nginx-efk

├── docker-compose.yml
├── fluentd
│   ├── conf
│   │   ├── conf.d
│   │   │   └── nginx.log.conf
│   │   └── fluent.conf
│   └── Dockerfile
└── nginx
    └── conf
        └── nginx.conf

ポイント

  • nginx のログ格納場所を volume 指定しホスト側とシンク。 それを fluentd 側でも volume 指定し tail するようにしました。

以下のようなイメージです。 f:id:kenzo0107:20170421221055p:plain

ブラウザから Nginx 起動確認

ブラウザから http://192.168.35.101/ にアクセスすると
Nginx の Welcome ページが確認できます。

f:id:kenzo0107:20170421222343p:plain

先程の docker-compose up 後に以下のようなログが見え
fluentd が Nginx アクセスログを捕まえているのがわかります。

f:id:kenzo0107:20170421222937p:plain

Kibana にアクセス

ブラウザから http://192.168.35.101:5601 にアクセスすると
Kibana ページが表示されます。

f:id:kenzo0107:20170421223008p:plain

  1. Index name or pattern

    • fluentd-* 指定
  2. Time-field name

    • @timestamp 指定
  3. Create ボタン押下

  4. レフトメニューから Discover クリック

f:id:kenzo0107:20170421223626p:plain

macOS からログ確認

当然ながら macOSvagrant とシンクしているので
macOS 上からもログが tail できます。

macOS%$ tail -f <path/to/vagrant-docker>/docker/nginx-efk/_log/nginx/access.log

以上です。 参考になれば幸いです。

AWS [Retirement Notification] 対応

f:id:kenzo0107:20170418105821p:plain

概要

とある日、AWS よりこんなメール通知が来ました。

要約すると
ホストしている基盤のハードウェアで回復不可能な障害が検知されたので 指定期限までに対応しないとインスタンスが停止する、とのこと。

今回こちらの対応をまとめました。

Dear Amazon EC2 Customer,

We have important news about your account (AWS Account ID: xxxxxxxxxxxx). EC2 has detected degradation of the underlying hardware hosting your Amazon EC2 instance (instance-ID: i-xxxxxxxx) in the ap-northeast-1 region. Due to this degradation, your instance could already be unreachable. After 2017-04-25 04:00 UTC your instance, which has an EBS volume as the root device, will be stopped.

You can see more information on your instances that are scheduled for retirement in the AWS Management Console (https://console.aws.amazon.com/ec2/v2/home?region=ap-northeast-1#Events)

* How does this affect you?
Your instance's root device is an EBS volume and the instance will be stopped after the specified retirement date. You can start it again at any time. Note that if you have EC2 instance store volumes attached to the instance, any data on these volumes will be lost when the instance is stopped or terminated as these volumes are physically attached to the host computer

* What do you need to do?
You may still be able to access the instance. We recommend that you replace the instance by creating an AMI of your instance and launch a new instance from the AMI. For more information please see Amazon Machine Images (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) in the EC2 User Guide. In case of difficulties stopping your EBS-backed instance, please see the Instance FAQ (http://aws.amazon.com/instance-help/#ebs-stuck-stopping).

* Why retirement?
AWS may schedule instances for retirement in cases where there is an unrecoverable issue with the underlying hardware. For more information about scheduled retirement events please see the EC2 user guide (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-retirement.html). To avoid single points of failure within critical applications, please refer to our architecture center for more information on implementing fault-tolerant architectures: http://aws.amazon.com/architecture

If you have any questions or concerns, you can contact the AWS Support Team on the community forums and via AWS Premium Support at: http://aws.amazon.com/support

Sincerely,
Amazon Web Services
  • AWS Console イベントを見ると一覧で表示されている。
    f:id:kenzo0107:20170418095219p:plain

  • AWS Console 詳細を見ると Notice が出ている。
    f:id:kenzo0107:20170411215054p:plain

ToDO

ボリュームタイプによって異なります。

今回は EBS ボリューム対応について記載してます。

対応

対象インスタンスが多かったのでローカルPC (macOS) から awscli でインスタンス停止→起動するシェル作成しました。
本番環境で利用されるインスタンスも含まれていた為、1件ずつ実行することとしました。

事前準備

$ brew install awscli jq
  • 各アカウント毎のアクセスキー、シークレットキー等設定
$ aws configure --profile <profile>
$ grep 'profile' ~/.aws/config

インスタンスの停止・再起動シェル

gist.github.com

以下のように実行すると
インスタンスが起動(running)していれば
停止後、再び起動し、ステータスチェックをするようにしました。

$ sh stop_and_start_ec2_instance.sh "<profile>" "<instance id>"

イベント情報取得シェル

.aws/config で設定されている profile を全てチェックし
未対応インスタンスのみ表示する様修正しました。

gist.github.com

結果確認

大体 1インスタンス 5分程度で完了。
問題なく停止起動でき、対象イベントが一覧から消えたことを確認しました♪

所感

メンテ対象インスタンスの Region が northeast に集中していたのが気になる点でした。
このインスタンス何に使ってるんだっけ?とならない様に、インスタンスやprivate key の命名ルール必須と感じました。

以上です。

Docker コマンド早見表

f:id:kenzo0107:20170414222435p:plain

バージョン

docker --version

Docker version 17.04.0-ce, build 4845c56

コンテナ

docker ps                     # running コンテナ一覧
docker ps -a                  # 全コンテナ一覧表示
docker start <CONTAINER ID>   # コンテナ起動
docker restart <CONTAINER ID> # コンテナ再起動
docker stop <CONTAINER ID>    # コンテナ終了
docker kill <CONTAINER ID>    # コンテナ強制終了
docker attach <CONTAINER ID>  # コンテナへアタッチ
docker top <CONTAINER ID>     # コンテナプロセスを表示
docker logs -f <CONTAINER ID> # コンテナログ表示
docker inspect <CONTAINER ID> # コンテナ情報表示
docker rm <CONTAINER ID>      # コンテナID指定でコンテナ削除
dockre rm <CONTAINER NAME...> # コンテナ名(複数)指定でコンテナ削除
docker container prune        # 停止コンテナを削除

dockr run -it -h <host name> <IMAGE>[:TAG] <command>  # イメージよりコンテナ起動 command 実施

イメージ

docker pull <IMAGE NAME>[:tag]     # イメージダウンロード
docker images ls              # イメージ一覧
docker inspect <IMAGE ID>     # イメージ情報表示
docker rmi <IMAGE ID>         # イメージ削除

イメージ作成

docker build -t NAME[:TAG]
docker commit -m "<comment here>" <CONTAINER ID> <IMAGE NAME>[:TAG]

Docker Compose

docker-compose up -d    # デタッチモードでイメージよりコンテナ起動
docker-compose ps       # コンテナ一覧表示
docker-compose stop     # docker compose 管理下全てのコンテナ停止
docker-compose start    # docker compose 管理下全てのコンテナ起動
docker-compose rm       # docker compose 管理下全ての停止コンテナ削除