スキップしてメイン コンテンツに移動

Terraformのど基本 - その３

 はじめに

前回の「 Terraformのど基本 - その２」ではTerraformを使用していくにあたってのよく使う基本のコマンドそしてそのコマンドを利用した大きな流れを確認した。

今回は早速Terraformを使ってサンプルでデモと行きたい所だが、まずはその為の下準備をここで行っておきたい。

ちなみにここではAWSを使用してサンプルを作成していく予定である。

準備

まずは何はともあれTerraformのインストールから行っていく。
$ brew install terraform
# 下記の様にバージョンが表示されればTerraformのインストールはOK
$ terraform -v
Terraform v0.15.3
on darwin_amd64
+ provider registry.terraform.io/hashicorp/aws v2.70.0
Your version of Terraform is out of date! The latest version
is 0.15.4. You can update by downloading from https://www.terraform.io/downloads.html
view raw install terraform hosted with ❤ by GitHub

続いてはAWS CLIを使える状態にしていく。ここで簡単にAWS CLIについて説明しておきたい。

AWS CLIとは？

一言で言い表すとコマンドでAWSの各サービスを扱う為のツール群である。AWS CLIを用いることによって、GUI上から操作していたものをコマンドに置き換えることが可能となるので、IaC化, DevOpsの流れとも相まってよく使われる様になっている。

AWS CLIのインストール

それではAWS CLIをインストールしていく。AWS CLIにはバージョンが１と２とが存在するが、基本的にはバージョン２をインストールすればOK。

AWS公式のダウンロードページより最新のパッケージのダウンロードを行い、インストーラーを起動しAWS CLIをダウンロードしていこう。リンクはmacOSのものだが、同ページには他のOSに関しても記載があるので都度参照されればと思う。

インストールが完了したら次はインストールの検証を行い、AWS CLIが意図通りインストールされているか、パスとバージョンを確認していく。下記の様なパスとバージョンが表示されればインストールは完了となる。
$ which aws
/usr/local/bin/aws
$ aws --version
aws-cli/2.2.3 Python/3.8.8 Darwin/20.5.0 exe/x86_64 prompt/off
view raw aws_cli_install hosted with ❤ by GitHub

IAMユーザーの作成

既にAWSが使用出来ている時点でrootユーザーのアカウントは作成されているかと思うが、実運用ではrootユーザーを使用するのはベストプラクティスではない為、新規でIAMユーザーを作成してAWSのリソースを扱っていく。

それでは早速新規でIAMユーザーを作成していこう。特に迷う点は無いと思われるが、ユーザー名を入力した後はアクセスの種類を選択する際に プログラムによるアクセスと AWSマネジメントコンソールへのアクセスにチェックを入れるのを忘れない様にしよう。










次に アクセス許可の設定（ポリシーの設定）を行っていく。本来であればグループをまず作成しグループに対してアクセス許可つまりはポリシーの設定を行うことでユーザーを管理しやすくすることが出来る（グループにユーザーを追加していくだけでポリシーが設定されることになる為、IAMユーザーを作成する度にポリシーをバインドするという手間が必要が無くなる）のだがここでは本筋とは少々ズレてしまうので割愛させて頂ければと思う。












運用方法によって変わるところではあると思うが、ここでは一先ず管理者権限である AdministratorAccess Policyをバインドしておこう。

タグに関しては特にここでは設定する必要が無いので、そのまま確認画面にて設定内容の確認を行いIAMユーザーの作成は完了となる。

ここで１点忘れずに注意しておきたいのが、作成直後に シークレットキーの情報が記載されたCSVファイルを必ずダウンロードする様にしておこう。（作成直後にしかダウンロードすることは出来ない仕様となっている）ここに記載されているシークレット情報がこの後CLIの設定を行うときにも必要となるからである。

もし万が一ここでダウンロードを忘れた場合は新規でアクセスキーを作成すれば良いだけの話なのでそこまで心配することも無いとは思う。

AWS CLIの設定

それではAWS CLIの設定を行う為の下準備が整ったので、AWS CLIをローカルから設定を行い上記で作成した認証情報を元にAWSのリソースをコマンドライン上から扱えるようにしていく。

aws configureコマンドを用いてAWS CLIをセットアップしていく。デフォルトではAWS CLIは defaultプロファイルを使用するが、ここでは --profileオプションを用いて aws-testという名前を割り当てる。この様に名前を割り当てることで、複数の認証情報と設定を使い分けることが可能となる。

最後に上記で作成した名前付きプロファイルを使用する為、環境変数 AWS_PROFILEを設定しておこう。この設定によりコマンドを叩く際にプロファイルの指定が不要となる。

# 参考: https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-quickstart.html
$ aws configure --profile aws-test
# 表示に従って取得したIAMユーザーの情報を入力
AWS Access Key ID [None]: AKIAI44QH8DHBEXAMPLE
AWS Secret Access Key [None]: je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY
Default region name [None]: us-east-1
Default output format [None]: （指定しない場合はデフォルトでjsonが使用される）
# 参考: https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-profiles.html
$ export AWS_PROFILE=aws-test
view raw aws_configure hosted with ❤ by GitHub
それではget-caller-identityを用いて設定が上手く出来たことを確認する為に承認テストを行って終わりとしたいと思う。

# IAMユーザアクセス権があることを確認
$ aws sts get-caller-identity
# 下記の様な認証情報が返却されればOK
{
"UserId": "ABCDEFGHIJKLMN",
"Account": "123456789",
"Arn": "arn:aws:iam::123456789:user/aws-test"
}
view raw get-caller-identity hosted with ❤ by GitHub

まとめ

今回はterraformを使っていく準備段階としてのAWS CLIの設定が主な内容であったが、最初慣れるまではAWS特有の概念などで戸惑うこともあると思うが、大まかな下記の流れを掴んでおくことが重要となる。
  1. AWS CLIのインストール
  2. IAMユーザーの作成（ポリシー周りの設定を含む）
  3. AWS CLIの設定
  4. 承認テスト
上記の点をざっくりと押さえておけば、後の細かいところはAWSのドキュメントにて詳細を参照していくことで更に理解が深まるハズ。

少々準備に時間を要したが次回はいよいよterraformを使ってサンプルのデモを行っていく。

P. S.
この記事に関する内容の誤りや改善提案などございましたら随時お待ちしております。

ラベル

ラベル:

コメント

コメントを投稿

このブログの人気の投稿

書評 -「UNIXという考え方」について - その３

    前回に引き続きMike Gancarz著の「UNIXという考え方」について、書評を書いていければと思う。 ４章 ソフトウェアが短命で終わるか否かは移植性を重視して作れるかどうかにかかっている ４章では効率より移植性が重要であり、例え効率を求めたとしてもそれは間もなく新しく来るスペックのものが来た時に残念ながらその努力はあまり意味を成さないものとなってしまうことがAtariの例も挙げられながら書かれている。 これはデータでも同様のことが言える。 取り巻く環境が変化することを前提にソフトウェアを書いていくこと。 その為繰り返し呼ばれている様な箇所以外で最適化にリソースを割き過ぎると環境が変化した時に対応することが困難になる。 その為にもまずは移植性を重視する必要がある。 環境が変化して、新しいハードウェアが登場しそこに移植さえ上手く出来れば前の世代のハードウェアで懸命に最適化して得られた効果よりももっと大きな効果を得られる。 昨今、もはやデファクトになり移植性の為にも無くてはならない存在になっているDocker。 従来以上に開発からサービスのリリースまでのスピーディーさが求められてる世の中になっている様にも感じるし、その為の環境もかつてよりかなり整備されてきている。 こういった環境の中で、効率性を上げるというよりかは、移植性を上げる方が将来的な環境の変化のことを考えると喫緊の課題と言える。 そもそも効率化や最適化を余りにも重視したところで、環境が変わって動かなくなれば元も子もないのだから。 「UNIXという考え方」の書籍の購入は こちら からどうぞ。 以上、５章へつづく。
2 件のコメント
続きを読む

書評 -「UNIXという考え方」について - その５

       前回に引き続きMike Gancarz著の「UNIXという考え方」について、書評を書いていければと思う。 ６章 過度の対話的インタフェースを避ける ６章では主に拘束的なインターフェース、プログラム、コマンドパーサーを避けなければならない理由について書かれている。 ソフトウェア設計者にとってのジレンマ 小さなプログラムやモジュールを数多く持つことで環境への適応能力は最大となるが、取り扱いも煩雑になる。 UNIXはユーザとモジュール間に広がる溝を少しずつ小さな塊または層にして減らしていこうとすることで解決を図る。 拘束的ユーザーインターフェース このアプローチの欠点は多くのアプリケーションが稼働するシステムだったり、あるコマンドを実行していてもそれを終わらせるまでは他のことが出来ない。 何故、避ける必要があるの？ UNIXユーザーにとってコマンド同士を対話させる必要がある。UNIX環境ではどのコマンドも単独では存在できない。様々な時点でコマンド同士が対話する前提だから。 拘束的プログラム ユーザーを人間と想定している為、人間の限界によって動作を制限されるようなシステムは、潜在能力をフルに発揮できない。 何故、避ける必要があるの？ 複雑になった拘束的プログラムは多機能主義と相まってますます大量のシステムリソースを必要とする。 ユーザーが人間であることを想定している為、他のプログラムとのインターフェースは苦手。 拘束的コマンドパーサー あらゆる可能性に対処しようとしてコマンドパーサーが肥大化し複雑になる。UNIXプログラマはユーザーインターフェースへの対処を避けて通る。典型的なUNIXアプリケーションにはコマンドパーサーがない。 その代わり、コマンド起動時にユーザがコマンドラインに動作パラメータも入力することが前提になっている。 何故、避ける必要があるの？ ソフトウェアのテコの効果を利用出来ず、他のプログラムとの対話を妨げるので、その効果をコンピュータ世界に広めることが出来ない。その為やがて取り残されて魅力を失っていく。 すべてのプログラムをフィルタにする 世界は、人間が作り出したデータで溢れている。コンピュータが発明されていなくても、データは存在している。 コンピュータは、データの収集とフィルタリングを効率よく行えるよう...
コメントを投稿
続きを読む

書評 -「UNIXという考え方」について - その４

      前回に引き続きMike Gancarz著の「UNIXという考え方」について、書評を書いていければと思う。 ５章 ソフトウェアのテコを有効に活用する 5章では主にソフトウェアのテコとシェルスクリプトのメリットについて書かれている。 よいプログラマはよいコードを書く。偉大なプログラマはよいコードを借りてくる 自分の仕事に他人の成果を取り込むことで、先人の努力を活かし、コードの有用性を一段と高めることができる。 独自技術症候群を避ける 既存のアプリケーションをゼロから設計し直すことは模倣であっても創造とは言わない。最も成功する会社は、他からソフトウェアを「借用」し、独自拡張を行う会社である。 コードを他社がテコとして使うのを認める ソフトウェアの寿命をコントロールしようとしても、プログラム開発への投資を一時的に保護することができるだけで、ソフトウェアそのものを保護することはできない。 すべてを自動化する コンピュータにできることを人間が手作業で行うのは時間の無駄。 シェルスクリプトのメリット テコの効果と移植性を高めるシェルスクリプトには何十ページ、数百コマンドラインに渡り、そこから呼ばれる各コマンドの背後にあるC言語のコードはものすごい量となる。これこそがテコの効果である。 時間が節約になる コンパイル段階を省略できるので、開発作業に集中できる。 Cより移植性が高い あるUNIXシステムで動作するスクリプトはほとんど修正なしで動作する。コンパイルはもちろん、どのような実行のための変換も不要。 C言語で書き直すという誘惑に負けない シェルスクリプトを次の年のマシンで使えば、もっと速く実行できるようになる。非常に移植性が高いのが普通だから、次の年のマシンに移植するのに特別な作業はほとんど何もない。 「UNIXという考え方」の書籍の購入は こちら からどうぞ。 以上、６章へつづく。
コメントを投稿
続きを読む