茶太郎の日記

クラウドやコンテナ辺り中心に技術をやっていきます

WSL2のInsider Previewでの提供が始まったのでWindows10 Homeで動かしてみた

最近Qiitaで書いたり会社のブログを書いたりしていてしばらく放置してしまっていました。

今回やってみたのはタイトルの通りです。

環境としてはWindows10 Homeとなってます。
ProではなくHomeでも使える、という話ですが、Hyper-Vの環境を使うとか使わないとか…
その辺よくわからないのでとりあえず詰まるところまでやってみよう、というノリでやってみましたが、結論から言うと問題なく動きました。

なお、Insider Previewって何？という状態からスタートなのでまずそこからやっていきます。

Windows 10 Insider Previewを有効化する

Windows Insider Program

  • [設定]>[更新とセキュリティ]>[Windows Insider Program]

更新とセキュリティ画面の一番下に Windows Insider Programがあるので、
そこからWindowsアカウントを登録していきます。（前からあったはずなのに目に入ってなかった。。）

f:id:chataro00:20190615115003p:plain

f:id:chataro00:20190615115857p:plain

Windows 10 Insider Preview 18917のインストール

登録を済ませてしばらくすると、
Windows 10 Insider Preview 18917.1000 (rs_prerelease)
がダウンロードされることになると思います。

ちなみに私はBuild1903などのインストールもあったので18917のダウンロード開始までもしばらくかかりましたが、
18917のダウンロード・インストールだけでも2時間近くかかりました。

再起動

Windows 10 Insider Preview 18917のインストールが完了すると再起動です。
ちなみに約5回以上再起動してました。

再起動祭り完了後にログインしたら、なぜか解像度やタスクバーの色が変わってました。。。

WSL2環境の構築

ここからは以下の公式サイトの手順に従って進めていきます。

docs.microsoft.com

VirtualMachinePlatformの有効化

PowerShellを管理者モードで起動し、以下のコマンドを実行します。

PS C:\WINDOWS\system32> Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform

出力はメモできませんでしたが、ここで再起動するかを確認されるので、Yを押して再び再起動します。

再起動後に再度同じコマンドを実行すると、今度は再起動は求められず、有効になっているようなメッセージが表示されます。

PS C:\WINDOWS\system32> Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform

Path          :
Online        : True
RestartNeeded : False

インストール済のWSLディストリビューションをWSL2に変換する

私はWSLのUbuntuをインストール済だったので、これを以下のコマンドでWSL2に変換しました。

PS C:\WINDOWS\system32> wsl --set-version Ubuntu 2
変換中です。この処理には数分かかることがあります...
WSL 2 との主な違いについては、https://aka.ms/wsl2 を参照してください
変換が完了しました。

数分と書いてありましたが、私の場合は30分ちょっとかかりました。

f:id:chataro00:20190615164702p:plain

変換コマンド実行前は取得していませんでしたが、
各ディストリビューションのバージョン情報は以下のように変化しました。

f:id:chataro00:20190615164905p:plain

WSL2環境を使ってみる

PowerShell上ではWSL2への変換が完了したので、実際に使ってみました。
とりあえず動いたという段階で書いているので大したことは試せていませんが、

  • Dockerはユーザーモード（非管理者モード）でも起動・実行可能
  • Docker networkの作成も可能
  • docker-composeも問題なく動く

ということが確認できました。

注意点としては

  • Windows10 HomeだけどHyper-Vが動いている模様
    • [アプリと機能]での有効化などは実施していません
  • そのためか、VirtualBoxでのVM起動はできなくなる

Windows上ではHyper-Vとその他の仮想マシンツールとは排他的、という話はよく聞くので、内部的にはHyper-Vが動いているように見えます。
VirtualBoxを活用している人はちょっとキツイですね。
Hyper-Vもフル機能使えれば問題ないでしょうけど、Homeではやはり無理そうです。おとなしくProにグレードアップすべきか。。。

ともあれWSL2で概ねフル機能のLinuxがWindows上で使えるようになったようなので、有効活用していきたいと思います。

GitLabのCI環境を構築してみる

gitlab

やってみたきっかけ

インフラCI実践ガイド を買って読み始めたことと、
Ansible Night in Tokyo 2018.09 のイベントでGitLabを使ったCIの話があったようで、
書いている時点ではまだ資料が上がっていませんが自分なりに試してみようと思いました。

Install GitLab-CE Core

動作要件

まずはGitLabを動かすのに必要なリソースを確認です。
docs.gitlab.com リンクを調べてみるとサーバはメジャーなLinuxなら大抵動くようなので
今回はVagrant(VirtualBox)でデプロイしたCentOS7にしました。
またMemoryは最低4GB/推奨8GBということでしたが念のために8GB、
CPUは2Coreが推奨でしたが100usersまでなら1Coreでも良さそうなので1Coreにしました。

インストール方法

次はGitLab(CE)のインストール方法です。 about.gitlab.com 手順がまとまっているのでほぼコピペで進められました。

1. Install and configure the necessary dependencies

sudo yum install -y curl policycoreutils-python openssh-server openssh-clients
sudo systemctl enable sshd
sudo systemctl start sshd

sudo firewall-cmd --permanent --add-service=http
sudo systemctl reload firewalld

この次にpostfixのインストールがありますが、Slack等の別の通知方法でよければskipしても良いとのことだったのでスキップしました。

2. Add the GitLab package repository and install the package

GitLabのパッケージなどが含まれているyumのリポジトリを追加します

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash

次にGitLabのパッケージインストールするのですが、
本文をよく見るとhttp://gitlab.example.comのところを環境に合わせて書き換えるように書いてあるのですが、
英語だったのでスルーしてそのまま入力してしまい後ほど少々困りましたが、
後から書き換えてreconfigureでちゃんと動きました。

sudo EXTERNAL_URL="http://gitlab.example.com" yum install -y gitlab-ce

↑のせいかもしれませんが、
「インストールとともにconfigureとstartが走ってURLにアクセスすれば繋がる」的なことが書いてあるのですが、
psなどを見て動いていなさそうだったのでインストールメッセージにあったコマンドを実行して起動させました。

sudo gitlab-ctl reconfigure

その後vagrantで割り当てたIPアドレスをブラウザに打ち込むとGitLabの画面が表示され、
rootのパスワード設定をしてメイン画面に入れました。

この段階でGitのリポジトリとしては十分動作します！

個人的に驚いたのはWeb IDE機能です。
Gitなのでしばらくはローカルからcommit & pushしていましたが、
ある程度のシンタックスが効いたりオートインデントしてくれるので、
ちょっとした変更ならWeb IDEでも良さそうです。
この辺はGitHubやAWSのCode Commitは弱いのでGitLabの意外な強みですね。

また色々説明が英語で書かれてて読み飛ばすとリスキーであることはわかったので、
ユーザ設定から言語を日本語に変更しました。言語を変えられるのは地味に助かりますね。
ただし新しい機能解説なのか英語のままというところもチラホラあるのでやっぱり英語は避けて通れませんね。

Install GitLab Runner

GitLabの自分的目玉であるCIをするには、当然何らかの実行基盤が必要です。
それを提供するのがGitLab Runnerです。

docs.gitlab.com

Admin Area -> 概要 -> Runner
にSetup a shared Runner manuallyとしてインストール方法のリンクが記載されています。

インストール方法

1. Simply download one of the binaries for your system:

# Linux x86-64
sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

2. Give it permissions to execute:

sudo chmod +x /usr/local/bin/gitlab-runner

3. Optionally, if you want to use Docker, install Docker with:

Optionallyと書いてありますが、DockerでCIを動かしたかったのでインストールしました

curl -sSL https://get.docker.com/ | sh

4. Create a GitLab CI user:

sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

5. Install and run as service:

(*) sudoだと/usr/local/bin/にPATHが通っておらず、ここはgitlab-runnerが叩けなかったのでrootで実行しました。

sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner start

Register the Runner

docs.gitlab.com

1. Run the following command:

GitLab Runnerのインストールが済んだら、GitLab Runner側でGitLabの情報を登録します。

sudo gitlab-runner register

こちらのコマンドを実行することで対話的に設定することができます。
（コマンドにオプションを追加することでワンライナーで設定することも可能なようです）

2. Enter your GitLab instance URL

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
http://<hostname>

3. Enter the token you obtained to register the Runner:

TOKENについては上記の
Admin Area -> 概要 -> Runner -> Setup a shared Runner manually -> 3.
に記載されています。

Please enter the gitlab-ci token for this runner
xxx

4. Enter a description for the Runner, you can change this later in GitLab's UI:

Please enter the gitlab-ci description for this runner
[hostame] gitlab01

5. Enter the tags associated with the Runner, you can change this later in GitLab's UI:

タグは適当に割り当てておきましたが、私の使い方だとあまり活用できてません。

Please enter the gitlab-ci tags for this runner (comma separated):
myself

6. Enter the Runner executor:

GitLab CIの実行環境を選びます。今回は先述の通りdockerを選択しました。いずれkubernetesなども使ってみたいですね。

Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
docker

7. If you chose Docker as your executor, you'll be asked for the default image to be used for projects that do not define one in .gitlab-ci.yml:

Docker Imageを指定しなかった場合のデフォルトのイメージを指定します。大抵指定すると思うのであまり考えずにコピペでalpine:latestにしました。

Please enter the Docker image (eg. ruby:2.1):
alpine:latest

これでgitlab-runner registerの設定は完了です。

Runnerの確認

次にGitLab側でRunnerが登録されたか確認します。
うまく登録されていれば以下のようにRunnerが表示されているはずです（ローカルなのでトークンも未加工でサボり） f:id:chataro00:20180925013307p:plain

この画面では表示されていませんが、同じようにインストールしていると最初はlockedというタグがついているかと思います。
この状態だとCIには使えないため解除する必要があります。

Runner tokenの列に記載されているIDをクリックしてRunnerの設定画面に入ります。 f:id:chataro00:20180925014129p:plain 現在のプロジェクトをロックするのチェックを外してロックを解除しました。((gitlab-runner registerのオプションで最初からロックしないようにできるようです))
また、先述したようにタグの設定が有効とCIの記述が増えて面倒なのでRun untagged jobsにチェックを入れます。
これでタグの付いていないジョブ（後述）が実行されるようになります。

GitLab CIの動作確認

最後にCIが意図通りに動いてくれるか確認します。
CIの設定はリポジトリ直下に.gitlab-ci.ymlというファイルを作って記載していきます。（ファイル名/パスはリポジトリごとの設定で変更できるようです）

image: alpine:latest
stages:
    - test
    - deploy

test1:
    stage: test
    script:
    - pwd
    - ls -lR

deploy:
    stage: deploy
    script:
    - apk add git
    - git status

記述していくパラメータは以下のようになります。((.gitlab-ci.ymlの書き方はまだ勉強中なので最小限です))

  • image 使用するコンテナイメージを指定
  • stages パイプライン上段に書かれる工程
  • <job>ジョブ名
    • stage stagesで指定したステージに紐付けます
    • script実行するコマンド

このように指定すると以下のようなパイプラインで実行されます。
各ジョブをクリックするとその実行経過＆結果が表示されます。

f:id:chataro00:20180925020101p:plain

注意すべき点は、ジョブ毎に実行するコンテナが別々になる、ということ。
そのため、pre-buildのようなジョブで何かを準備していても、別のジョブではその準備が引き継がれません。
この辺りはもしかしたらうまい方法があるかもしれないので調査するとともに情報提供お待ちしています。

次にやったこと（次回予告）

次にやったことは、
PackerのAnsible Provisonerを使ってAMIをCI/CDする です。

ですが、今回はここまでにして次回に解説を回したいと思います。

一応順次更新中ですがGitLabにおいているのと同じリポジトリをGitHubに置いておきましたので、先に見たい方はご覧ください。

github.com

Ansibleのベストプラクティスに学ぶ

Ansible

しばらく更新が開いてしまいました。

今年の前半はDockerやKubernetesに追いかけていたのですが、
近頃は仕事でAWS*1とAnsibleを中心に使っているため、関心もそちらに寄ってきています。

今回はAnsibleのベストプラクティスについて勉強したので書いていきます。

Ansibleのベストプラクティスとは

「ベストプラクティスとは大きく出たな 」
「そもそも何のベストプラクティスなんだろう？」
とお思いの方もいるかも知れませんが、 Ansibleでは公式でベストプラクティスを公開しています。
Best Practices — Ansible Documentation

こちらを見てみると分かる通り、ファイルやディレクトリの構成のようです。
Ansibleではご存知の通り様々なファイルが使用されます。
大きく分けるとプレイブックとインベントリの2つが中心ですが、細かい挙動などをファイル毎に分けていくとかなりの数に分類されます。
それをうまく活用しつつ、キレイに配置しよう、というのがベストプラクティスと呼ばれるものだと思います。

公式サイトでは2種類のベストプラクティスを紹介しています。

ベストプラクティスな構成を作ってみる

ドキュメントを読んでいても（英語だし）いまいちピンとこなかったので、
ベストプラクティスを真似た構成を作ってみました。
手前味噌ですが、練習用も兼ねてリポジトリを作っています。 github.com ちなみに今の仕事でも商用/検証環境が別れているのでAlternative Directory Layoutのほうをベースにしています。

インベントリの構成

ディレクトリ構成は以下のようになっています。

.
├── inventory
│   ├── production
│   │   ├── group_vars
│   │   │   ├── all.yml
│   │   │   ├── app.yml
│   │   │   ├── db.yml
│   │   │   └── web.yml
│   │   ├── hosts
│   │   └── host_vars
│   │       └── webserver2.yml
│   └── staging
│       ├── group_vars
│       │   ├── all.yml
│       │   ├── app.yml
│       │   ├── db.yml
│       │   └── web.yml
│       ├── hosts
│       └── host_vars

インベントリファイルの内容は以下のようです。

$ cat inventory/production/hosts
[web]
webserver1
webserver2

[app]
appserver

[db]
dbserver

変数はすべてgroup_vars, host_varsに記載しています。
ProductionとStagingで同じようなグループ構成にしつつ
IPアドレスやパラメータの違いを*_varsで吸収させることで、
共通のPlaybookを使うことができるのが良さですね。

各種の変数には強弱というか優先順位があります。
Variables — Ansible Documentation

思っている以上に数があって覚えるのは大変そうですし、よく使うのはこの辺りです。*2

↑ 弱い
* role defaults
* inventory group_vars/all
* inventory group_vars/
* inventory host_vars/
* include_vars
↓ 強い

role defaultsは最も弱い変数なのでデフォルト値として、他の変数に上書きされたりするんですね。
でも、バージョンアップの対応として高いバージョンをhost_vars→group_varsと段階的にバージョンアップしていき、
確証が取れたら最終的にdefaultsのバージョンを上げる、というような使い方もできます。 include_varsなどの強力な変数はほぼ上書きできないので、もはや定数みたいな扱いですね。

こういった変数の構成はプログラミングのようでInfrastructure as Codeしている感があって好きですね。

ロールの構成

ロールを作っているうちに「大した仕事させない割にはすごいファイル数だな…」と感じました。
Tipsですが、ロールを作るのにいちいち特定のディレクトリ名を作るのが面倒だと思い調べたところ、
ansible-galaxy init というコマンドを知りました。

$ ansible-galaxy init common/hoge --offline
- common/hoge was created successfully
$ tree common/hoge/
common/hoge/
├── defaults
│   └── main.yml
├── files
├── handlers
│   └── main.yml
├── meta
│   └── main.yml
├── README.md
├── tasks
│   └── main.yml
├── templates
├── tests
│   ├── inventory
│   └── test.yml
└── vars
    └── main.yml

8 directories, 8 files

上のように、ロールで使われるディレクトリを1コマンドで一気に作ってくれます。
(デフォルトではAnsible Galaxyのサイトを一度見に行くようなので--offlineを付けることでローカル実行で早く終わるようです）

ちなみにリポジトリの方はまだ挙動を知る段階なので見やすさ重視で不要なディレクトリ/ファイルは削除してます。
でもtestsとか気になるのでいずれ触ってみたいと思います。*3

最後に

今回Ansible公式のベストプラクティスを紹介しましたが、
Qiitaなどで見ると俺的ベストプラクティスがいくつか紹介されています。
環境によっても使い方は様々だと思うので、実環境での使いやすさや好みでベストな構成を考えるのも良いのかもしれません。
私も「これだ！」という構成を見つけるまでは公式のベストプラクティスをベースで作っていきたいと思います。*4

*1:AWSはSAAがそろそろ失効してしまうのでSAPに昇格して更新しようと模試を受けたらボロボロだったので、そちらは同じモノを更新か、他のアソシエイトのものに挑戦しようかと思ってます。

*2:他のもののうまい使い方があれば教えてください！

*3:testsを活用されていたら教えていただけると嬉しいです

*4:ちなみに今回このテーマを取り上げた理由は、今の仕事の構成がアンチパターンだから。。。

一週間遅れのAWS Summit Tokyo 2018 (Day1) の私的まとめ

土日にガッツリ風邪を引いてしまったのでタイミングを逃してしまいましたが、
AWS Summit Tokyo 2018 (Day1) に参加してきたのでまとめのレポートになります。

一応セッションの予約は開始日に登録したのですが、
なかなか繋がらなくて繋がったと思ったらかなり埋まっているという惨状で、
とりあえず空いてるところに予約入れた感じでキャンセル待ちとか見直ししてなかったので、
若干なんでこれ申し込んだんだっけ？みたいなのもありましたが、
どれも内容が濃くていい刺激がもらえました。

事例でわかる、AWS 運用を支えるサポート活用方法とエンタープライズサポートという選択

クックパッド株式会社 インフラストラクチャー部部長　星 北斗さん

加入サポートプランの経緯

  • ~2016
    • Developer Support $49/month　（初回応答に３営業日）
      • インフラの管理は全てインフラ部がやる
      • AWSに関するノウハウは全てインフラ部に集約
      • 「僕らがわかるのになんで高いお金を払わないといけないの？」
  • 2016~
    • enterprise $15,000～/month

何があった？

  • 2016年に激動の変化

    • 経営体制、方針の変更
    • （登壇者の）インフラ部部長昇格

  • 中央管理の限界

    • インフラ部（＋自分自身）がボトルネックになってしまった
      • 本来やるべきことに時間を使う必要があった
        • × AWSの検証・管理
        • ○ ユーザにサービスを届けること
    • そもそもAWSの利点が活かせていないのでは？
    • 自律分散できる仕組みに変えなければ先がない状況

どういう状態を目指したのか

  • 誰もが人にお伺いを立てずとも自身で前に進める状態へ
  • 中央集権の廃止
  • 自律化=セルフサービス化

エンタープライズサポートの選択

  • 気兼ねなく質問できる環境
  • 「我々がノウハウを貯めるよりノウハウを引き出すほうが良い」
  • TAMアサイン

エンタープライズサポートの実際

  • サポートケースの使い方
    • 権限を全てのユーザに解放し誰でも使えるように
    • 補足が必要な質問などには横から割り込み
    • とにかく「カジュアルに質問できる」環境を作る
    • 全開発者がインフラ部に気兼ねすることなく質問できる
  • アカウントコンシェルジュ
    • エンタープライズサポート専属のコンシェルジュ
    • 複雑な料金体系への理解が深い
    • サービス公開前などに手伝ってもらえるのが最高
    • AWSの色々なサービスを使っていくのにとても助かる存在
  • TAMアサイン
    • ビジネスの流れを理解しながらAWS(以外の技術も！)の技術を相談できる相談役
    • SAなどとSlackでカジュアルに質問に答えてくれる
    • 障害などの動向を常に把握しつつ注意喚起してくれる
  • アカウントチーム
    • TAM, SA（ソリューションアーキテクト）, 営業などがサポート
    • 普段からSlack上にいてくれる
    • チャンネル公開して全社員誰でも相談できるようにしている
    • 新しいサービスの構成などについても相談しながら進められる

TAMとSA

  • TAM
    • AWSサービスを『もっと使いこなす方法』を一緒に考える
  • SA
    • サービス特性を理解し、AWSサービスを使って『やりたいことをどう実現するか』一緒に考える

エンタープライズにしてみて

  • 強力な味方を得ることによって「使いこなし」がさらにできるようになる
    • サービスの幅が広がり、どちらにせよ全領域一人でカバーするのは難しかった
  • お値段以上！

ソニー株式会社 ブランドデザインPF UX事業開発部門 経営企画課　伊藤 哲也さん

  • DevOps前後でアカウント数が増えた
  • AWS Organizationでマスターアカウントでサポートに加入

エンタープライズサポートのコミュニケーション対策

  • サポートはアカウントごとに閉じているため、同じ質問が重複してしまう
  • マスタアカウント不在の時にサポートを受けられない
    • [対策] これもAWSサポートと協力して直接やり取りしてくれる仕組みを作ってくれた

その他の恩恵

  • コンシェルジュが費用分析してくれる
    • 自力で詳細レポートから分析するのは困難

AWS Well-Architected Framework (以後AWS W-A)

  • AWSの各フェーズにおけるベストプラクティス集
    • 要件検討
    • 設計
    • 構築
    • 運用
  • 柱ごとのホワイトペーパーとチェックリストでチェックできる
    • セキュリティ
    • 信頼性
    • パフォーマンス
    • コスト
    • 運用性
  • あくまでベストプラクティス
    • リスクを把握できていることが重要
    • 対処するかはビジネス判断
  • 一度だけでなく定期的な見直しが必要
    • Ever Green：常に枯れないシステムを目指してほしい

セキュリティ入門1

クラスメソッド

予防的統制

あらかじめ想定されるリスクの発現を予防するためのもの

2 * 3 = 計6軸の観点

/ リスク評価 リスク対処
インフラストラクチャ 1 4
データ 2 5
論理アクセス管理 3 6
  • リスク評価の1, 2, 3にはいずれもW-AとTrusted Advisorが入る
  • その他全てに対応するサービスがある（リンク参照）

セキュリティ入門2

クラスメソッド

発見的統制

あらかじめ想定したリスクと未知の驚異の発現をあらゆるイベントから検知し、
その影響を抑えるためのもの

  • イベントの管理
    • CloudWatch
      • APIの操作からOS・アプリのログまでAWS内のイベントはほぼ網羅して集められる
  • インシデントの検知
    • GuardDuty
      • セキュリティの観点から脅威リスクを検知するAWSマネージドサービス
      • 機械学習でリスクを判定してくれるらしい
        • ソースはJVNなど
  • インシデントに対するアクション
    • セキュリティ・オートメーション
      • GuardDuty ＞ CloudWatch Event ＞ Lambda/StepFunctionのような流れで概ね自動で対処までできてしまう
        • LambdaからAWS Systems ManagerのRun Commandからyum updateさせたり

私的所感

  • サポートは直接手は動かしてくれないが、豊富な経験・知識から技術面・サービス面で協力にサポートしてくれる
    • サービスを作るための生産性に最大限寄与する
    • 変なSIerから数人雇うより圧倒的に強力
      • 頼もしいと思うとともにSIerにいる身としては危機感を感じた
      • APNパートナーでも太刀打ちできるのか？というレベル
      • AWSが意図しているかは別だが、SIerの価値が下がる・排除される構図は確実に出来上がってきている
  • （運用）自動化という言葉はあまり聞かなかったが、セキュリティ・オートメーションはまさに運用自動化
    • すでに自動化は当たり前になっていて、自動化しにくかったセキュリティ領域もできるようになってきている状況だと感じた
  • W-Aの話の中で「東京リージョンにする必要がありますか？」という話でハッとした
    • EC2などモノによっては40%も価格が違う
    • レイテンシはCloudFrontで差がなくせる
    • 新サービスをいち早く導入できるのもメリット

余談ですが１年半前にソリューションアーキテクト（アソシエイト）を取得していたので、
認定者用ラウンジでシールをもらえました！
早速PCに貼りました！！
失効前にプロフェッショナルを取得して新しいシールを貰おうというモチベも上がりました！

f:id:chataro00:20180606222032j:plain

AWSで秘密鍵・公開鍵を複数環境で利用する

AWS EC2

AWSを使い始めて、EC2でインスタンスを立ち上げることができたけど、
この先何しようか？とか、もっとうまく活用したい、という方向けに
知ってること、調べたことなどのTipsをアウトプットしていきたいと思います。

秘密鍵・公開鍵を複数環境で利用する

新しい環境でEC2を作成する際にAWS側にキーペアがない場合は、
AWS側でキーペアを作成し、秘密鍵をダウンロードしてそれを使ってsshするかと思います。

しかしこのキーペアが利用できる範囲はap-northeast-1などのリージョンに限られます。
複数のリージョンを使い分けたい場合や、サービス等によっては複数のアカウントの環境もある場合、
（サービス数）×（利用リージョン数）
ものキーペアを発行することになり、ログインするときにどの鍵を使うかの管理が煩雑になりそうです。

そうならないためにはAWS側にキーペアの作成に作成させるのではなく、
キーペアのインポートを利用すると１つのキーペアを複数環境に配置することが可能です。

GUI(マネジメントコンソール)の場合

EC2サービスの画面にある ネットワーク & セキュリティ > キーペアのメニューを開きます。

f:id:chataro00:20180331151016p:plain:w100

するとキーペアの作成の他にキーペアのインポートというメニューがあります。

f:id:chataro00:20180331151716p:plain:w200

そちらをクリックすると以下のような画面が出てきます。

f:id:chataro00:20180331151918p:plain:w300

キーペア名はAWS上で表示される名前なので任意の名前を決めてください。
インポート方法としては2種類あり、

  • パブリックキー（公開鍵）をファイルとしてアップする方法
  • パブリックキー（公開鍵）の内容をテキストボックスにコピペする方法

があります。

環境にもよるかもしれませんが、エクスプローラーで公開鍵のファイルを選ぶのは面倒なので、私は後者がオススメです。
また、間違っても秘密鍵のほうをアップロードしないようにしましょう。
（多分エラーが出てアップロードされないだけで危険はないかと思いますが）

AWS CLIの場合

AWS CLIからであればもっと簡単に実施できます。
AWS CLIがインストール済の前提ですが、そちらも後日記事にしたいと思います。

ユーザーのデフォルトの鍵を使ってhogehogeというキーペア名で作る場合は以下のようになります。

$ aws ec2 import-key-pair --key-name hogehoge --public-key-material "`cat ~/.ssh/id_rsa.pub`"

コマンドが成功していれば以下のような出力が出ます。

{
    "KeyName": "hogehoge",
    "KeyFingerprint": "（フィンガープリント）"
}

あとは実際に作成されたキーペアを使ったEC2インスタンスにログインできれば成功です！

今更ながらデブサミでプレゼンしたことを書いてみる

ブログを書こう書こうと思いつつ始めてませんでしたが、
デブサミ登壇というちょうどいいネタがあったので（といいつつ1ヶ月も経っちゃったけど）
その時のことなどから書いていこうと思います。

www.slideshare.net

スライドはSlideShareにアップしていますが、
スピーカーノートに書いててプレゼンの場でしか伝えられなかったことがそこそこあります。