2023.05.26

【実践】TerraformのinstallからAWS EC2の作成〜ssh接続までを実践してみた

Terraformとは、インフラストラクチャを管理するためのオープンソースのツールです。こちらの記事では、Terraformを使用してAWSのEC2を作成し、ssh接続するまでの流れをご紹介します。

記事を通して、Terraformとはどういったものなのかを理解していただければ幸いです。

Terraformとは

Terraformは、インフラ環境をコードで定義して構築するIaC(Infrastructure as Code)ツールの一つで、アメリカのソフトウェア企業であるHashiCorp社が開発したオープンソースツールです。HCL(HashiCorp Configuration Language）と呼ばれる独自の言語を使用しており、JSONやYAMLと同じような形式で記述をすることができ、読みやすく保守しやすいといった特徴があります。

また、Terraformでは主に、準備、計画、実行、削除の4つを管理するだけというシンプルさを持っており、最低限この4つのコマンドさえ覚えていればTerraformを扱えるというのも特徴の一つです。

IaCのメリットやIaCツールについては以下の記事で解説しています。

https://envader.plus/article/136

様々なクラウドに対応している

今回のハンズオンでは利用するクラウドとしてAWSを使用しますが、TerraformはGCPやAzureなど複数のクラウドに対応しています。AWSやGCPにも独自のIaCを実現できるAWS CloudFormationやCloud Development Managerがありますが、これらは自身のクラウドにしか対応していません。それぞれ自身のクラウドに特化したメリットもありますが、Terraformであれば一つのツールで複数のクラウドに対応しているという点も魅力の一つと言えるでしょう。

環境の準備

初めにAWS CLIのインストールやTerraformのインストールを行い、環境構築をおこないます。今回実施する内容はMacOS環境で実施しました。参考にされる場合には、WindowsやLinux環境など、適宜置き換えて実施するようお願いいたします。

AWS CLIのインストール

以下の公式サイトを参考に、AWS CLIをインストールします。AWS CLIとは、AWS Command Line Interfaceの略で、AWSの提供するサービスをコマンドラインから制御することが可能になります。

AWS CLIインストールガイド

はじめに、curlコマンドを使用し必要なファイルをダウンロードします。今回はホームディレクトリへダウンロードしました。

$ curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"

次に、以下のコマンドでインストーラプログラムを実行し、pkgファイルをインストールします。

$ sudo installer -pkg ./AWSCLIV2.pkg -target /

インストール完了後、以下のコマンドをターミナルで実行して、AWS CLIがインストールされたか確認します。

$ aws --version #以下のように表示されればOK
aws-cli/2.8.0 Python/3.9.11 Darwin/22.3.0 exe/x86_64 prompt/off

プロファイルの設定

AWSプロファイル(設定と認証情報)を作成します。プロファイルを作成することによって、どのユーザーがどのAWSリージョンを使用するのか、AWSにアクセスする際のユーザーごとのシークレットアクセスキーやアクセスキーIDの設定をすることができます。

今回は事前に作成していたIAMユーザーのシークレットアクセスキーとアクセスキーIDを使用しました。この場合にはユーザー名はdefaultとなります。

$ aws configure

AWS Access Key ID [None]: #作成したアクセスキーを入力
AWS Secret Access Key [None]: #作成したシークレットキーを入力
Default region name [None]: ap-northeast-1 #今回はap-northeast-1と入力
Default output format [None]: #入力なし

設定が完了すると、ホームディレクトリ配下に以下のファイルが作成されます。

# ~/.aws/credentials 認証情報が記載されるファイル
[default]
aws_access_key_id = *****************
aws_secret_access_key = *********************

# ~/.aws/config ユーザーごとに設定した内容が記載されるファイル
[default]
region = ap-northeast-1

ここまでで、AWS CLIの設定は完了です。

tfenvのインストール

AWS CLIの設定が完了したら、Terraformをインストールします。Terraformのインストールには大きく分けて二つの方法があります。Terraform公式ページで紹介されているHomebrewを使用してインストールする方法と、Terraformのバージョンの切り替えができるtfenvを使用する方法です。

今回はtfenvをインストールしていきます。

tfenv

Homebrewを使用してtfenvをインストールします。

$ brew install tfenv
==> Fetching dependencies for tfenv: grep
(略)
==> Running `brew cleanup tfenv`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).brew install tfenv

インストールが完了したら、tfenvコマンドが使えるか確認します。

$ tfenv # コマンドを実行

tfenv 3.0.0
Usage: tfenv <command> [<options>]

Commands:
   install       Install a specific version of Terraform
   use           Switch a version to use
   uninstall     Uninstall a specific version of Terraform
   list          List all installed versions
   list-remote   List all installable versions
   version-name  Print current version
   init          Update environment to use tfenv correctly.
   pin           Write the current active version to ./.terraform-version

tfenvでインストールできるTerraformのバージョン確認

次に、tfenvコマンドでインストールできるバージョンの一覧を以下のコマンドで確認します。

$ tfenv list-remote

1.5.0-alpha20230504
1.5.0-alpha20230405
1.4.6
1.4.5
1.4.4
1.4.3
1.4.2
以下省略

バージョンを指定してインストールする

以下のコマンドを使用することで、Terraformのバージョンを指定してインストールすることができます。

$ tfenv install 1.4.6
Installing Terraform v1.4.6
Downloading release tarball from https://releases.hashicorp.com/terraform/1.4.6/terraform_1.4.6_darwin_amd64.zip
############################################################################################################################################### 100.0%
# 省略
Installation of terraform v1.4.6 successful. To make this your default version, run 'tfenv use 1.4.6'

指定したバージョンがインストールできているか確認します。

$ tfenv list
  1.4.6
* 1.3.9 (set by /usr/local/Cellar/tfenv/3.0.0/version)

インストールしたバージョンを使用するため、以下のコマンドでバージョンを指定します。

$ tfenv use 1.4.6
Switching default version to v1.4.6
Default version (when not overridden by .terraform-version or TFENV_TERRAFORM_VERSION) is now: 1.4.6

これでTerraformを実行する準備が整いました。

Terraformの基本コマンド

Terraformの準備が完了したので、基本となるコマンドを確認します。

terraform init

公式ドキュメント

Terraformを実行する作業ディレクトリを初期化するコマンドです。このコマンドを実行することで、Terraformが必要とするバックエンドの設定やAWSやGCPなどのプロバイダーのダウンロード、セットアップが自動的に行われます。コマンドの実行が完了すると、カレントディレクトリに.terraformファイルが作成されます。公式によると、initコマンドは複数回実行しても問題ないとされています。

terraform plan

公式ドキュメント

Terraformでどんな変更を行うのかを予測するコマンドになります。コマンドを実行すると、どのようなインフラ構成の作成、修正、削除などの変更が行われるのかをプレビューすることができます。

すでに存在するリモートのオブジェクトの状態を読み込み、ソースコードとの差分を表示してくれる機能になります。

terraform apply

公式ドキュメント

terraform planで表示された変更内容を実行するコマンドです。このコマンドを実行すると、設定したプロバイダ上に自動的にインスタンスなどが生成されます。

terraform destroy

公式ドキュメント

作成したリモートのオブジェクト(インスタンス)を削除することができます。このコマンドを実行すると、applyで作成したインスタンスを自動的に削除します。

terraform fmt

公式ドキュメント

プロジェクト内のソースコードを自動で整形してくれ、フォーマットを整えてくれるコマンドです。コマンドを実行することでコードが整形されて見やすくなります。

また、terraform fmt -recursiveとすることで、再起的に下層ディレクトリ内もフォーマットしてくれます。

terraform validate

公式ドキュメント

Terraformのコードが構文的に正しいかどうかを確認することができます。.tfファイルを検証し、構文エラーがある場合にはエラーメッセージが表示されます。あくまで構文エラーのチェックを行うコマンドのため、作成するリソースの正当性などのチェックは行われません。

Terraformの実践

ここからはTerraformを使ってAWS上にEC2を作成し、SSH接続を行います。

今回は作業ディレクトリとして、terraform-ec2ディレクトリを作成しました。

Terraformとプロバイダの設定

作成したディレクトリにversions.tfファイルを作成します。

touch versions.tf

作成したversions.tfファイルに、具体的に必要なプロバイダとバージョン、Terraform自体のバージョンを設定します。

# terraform-ec2/versions.tf

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 4.49.0"
    }
  }

  required_version = "~> 1.4.0"
}

provider "aws" {
  region = "ap-northeast-1"
}

terraform{}ブロックでは、実行に必要なプロバイダとそのバージョン、そしてTerraform自体のバージョンを指定しています。

required_providers{}ブロックで、Terraform設定が依存するプロバイダとそのバージョンを指定します。Terraformは多数のプロバイダ（AWS, GCP, Azureなど）をサポートしているため、このブロックにより必要とするプロバイダを明示的に宣言できます。

今回はawsプロバイダを使用することを宣言し、sourceでプロバイダをHashiCorp社がメンテナンスするレジストリから取得するよう指定しています。versionではawsプロバイダのバージョンを指定することができます。今回は4.49.0以上を利用することにしました。

required_versionではTerraform自体のバージョンを指定しています。今回使用するTerraformのバージョンはtfenvコマンドでインストールした1.4.6のため、~> 1.4.0としています。

最後の行のprovider{}ブロックでは、AWSプロバイダでどのリージョンを使用するのかを示しています。今回はap-northeast-1(東京リージョン)を指定しています。

ここまで完了したら、terraform initコマンドを実行し作業ディレクトリの初期化を行います。

$ terraform init

Initializing the backend...

Initializing provider plugins...
- Reusing previous version of hashicorp/aws from the dependency lock file
- Using previously-installed hashicorp/aws v4.66.1

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

無事初期化が完了しました。

インプット変数の作成

Terraformは変数で値を動的に取得することができます。変数には種類があり、インプット変数、ローカル変数、アウトプット変数の3つの種類があります。

ここでは今回作成するにあたり必要なインプット変数を、variables.tfファイルを作成し定義します。

# variables.tf

variable "project" {
  type = string
}

variable "environment" {
  type = string
}

variable "vpc_cidr" {
  type        = string
  description = "vpc cidrblock"
}

variable "subnet_cidr" {
  type        = string
  description = "public subnet cidr"
}

variableでインプット変数を定義し、ダブルクウォートの中に使用する変数名を指定しています。インプット変数ブロックでは変数名、データ型、デフォルト値、説明を記述することができます。

このインプット変数に値を代入するには以下のような方法があります。

環境変数を使う
plan、applyを実行した際に代入する
.tfvarsファイルを作成し、variables.tfファイルに定義した変数の値を記述する

今回は3番目の.tfvarsファイルを作成する方法で変数の値を設定しました。

.tfvarsファイルの作成

.tfvarsファイルに代入したい変数の値を記述していきます。今回使用するファイル名は、terraform.tfvarsとします。ファイル名をterraform.tfvarsとすることによって、Terraformは自動的にそのファイルに変数の値が定義されていると認識し、優先的にファイルが読み込まれます。こうすることで、planやapplyといったコマンドを実行する際にterraform apply -var="image_id=ami-abc123”のように毎回のコマンド実行時に変数の値を渡す必要がなくなります。

公式ドキュメント

# terraform.tfvars

project = "create-EC2"

environment = "dev"

vpc_cidr = "10.0.0.0/16"

subnet_cidr = "10.0.1.0/24"

このような形で記述し、variables.tfファイルで宣言した変数名に値を代入します。今回は全て文字列のためダブルクウォートで囲んでいますが、数値型の場合にはダブルクウォートは必要ありません。

変数の値を参照する

代入した変数の値を参照する方法は以下の通りです。

var.<変数名>
# 例
var.project # create-EC2が参照される

${}とすると、文字列の中に変数の値を埋め込むことができます。

Name    = "${var.project}-${var.environment}-vpc"
# create-EC2-dev-vpcとなる

VPCとサブネットの作成

VPCとサブネットを作成していきます。Terraformには色々なディレクトリ構成やファイルの分け方があり、それぞれのプロジェクトによってベストプラクティスは異なると思います。今回はテストということもあり、VPC、サブネット、ルートテーブル、インターネットゲートウェイをnetwork.tfファイルを作成し、その中に定義していきます。

# network.tf
# VPC
resource "aws_vpc" "main" {
  cidr_block                       = var.vpc_cidr
  instance_tenancy                 = "default"
  assign_generated_ipv6_cidr_block = false

  tags = {
    Name    = "${var.project}-${var.environment}-vpc"
    Project = var.project
    Env     = var.environment
  }
}

# Subnet
resource "aws_subnet" "public" {
  vpc_id                  = aws_vpc.main.id
  availability_zone       = "ap-northeast-1a"
  cidr_block              = var.subnet_cidr
  map_public_ip_on_launch = true

  tags = {
    Name    = "${var.project}-${var.environment}-public-subnet"
    Project = var.project
    Env     = var.environment
    Type    = "public"
  }
}

Terraformでは、VPCなど一つのリソースごとにresourceブロックを作成し、必要な設定を記述していきます。構文は以下になります。

resource "リソースの種類" "リソース名"{}

リソースの種類や各設定項目はTerraformであらかじめ定義されているため、公式ドキュメントを参照しましょう。リソース名は任意の名前が設定可能です。作成した別のファイルなどで参照する必要があるため、分かりやすい名前にします。

ここまで完了したらterraform fmtでコードを整形して、terraform planを実行しプレビューを実行します。

$ terraform plan

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_subnet.public will be created
  + resource "aws_subnet" "public" {
      + arn                                            = (known after apply)
      + assign_ipv6_address_on_creation                = false
      + availability_zone                              = "ap-northeast-1a"
      + availability_zone_id                           = (known after apply)
      + cidr_block                                     = "10.0.1.0/24"
      + enable_dns64                                   = false
      + enable_resource_name_dns_a_record_on_launch    = false
      + enable_resource_name_dns_aaaa_record_on_launch = false
      + id                                             = (known after apply)
      + ipv6_cidr_block_association_id                 = (known after apply)
      + ipv6_native                                    = false
      + map_public_ip_on_launch                        = true
      + owner_id                                       = (known after apply)
      + private_dns_hostname_type_on_launch            = (known after apply)
      + tags                                           = {
          + "Env"     = "dev"
          + "Name"    = "create-EC2-dev-public-subnet"
          + "Project" = "create-EC2"
          + "Type"    = "public"
        }
      + tags_all                                       = {
          + "Env"     = "dev"
          + "Name"    = "create-EC2-dev-public-subnet"
          + "Project" = "create-EC2"
          + "Type"    = "public"
        }
      + vpc_id                                         = (known after apply)
    }

  # aws_vpc.main will be created
  + resource "aws_vpc" "main" {
      + arn                                  = (known after apply)
      + assign_generated_ipv6_cidr_block     = false
      + cidr_block                           = "10.0.0.0/16"
      + default_network_acl_id               = (known after apply)
      + default_route_table_id               = (known after apply)
      + default_security_group_id            = (known after apply)
      + dhcp_options_id                      = (known after apply)
      + enable_classiclink                   = (known after apply)
      + enable_classiclink_dns_support       = (known after apply)
      + enable_dns_hostnames                 = (known after apply)
      + enable_dns_support                   = true
      + enable_network_address_usage_metrics = (known after apply)
      + id                                   = (known after apply)
      + instance_tenancy                     = "default"
      + ipv6_association_id                  = (known after apply)
      + ipv6_cidr_block                      = (known after apply)
      + ipv6_cidr_block_network_border_group = (known after apply)
      + main_route_table_id                  = (known after apply)
      + owner_id                             = (known after apply)
      + tags                                 = {
          + "Env"     = "dev"
          + "Name"    = "create-EC2-dev-vpc"
          + "Project" = "create-EC2"
        }
      + tags_all                             = {
          + "Env"     = "dev"
          + "Name"    = "create-EC2-dev-vpc"
          + "Project" = "create-EC2"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

特にエラーもなくプレビューすることができました。AWS上にデプロイするため、applyを実行します。applyを実行する際、-auto-approveをつけるとデプロイする際に聞かれる質問をスキップすることができます。

$ terraform apply -auto-approve

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

~~省略~~
Plan: 2 to add, 0 to change, 0 to destroy.
aws_vpc.main: Creating...
aws_vpc.main: Creation complete after 1s [id=vpc-02d0f841f66449407]
aws_subnet.public: Creating...
aws_subnet.public: Still creating... [10s elapsed]
aws_subnet.public: Creation complete after 11s [id=subnet-0359cf292da62ead3]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

エラーもなくデプロイできたようなので、マネジメントコンソールで作成できたか確認します。

コードのtagsで記述したNameの値でVPC、サブネットが作成されています。次はルートテーブルを作成します。

ルートテーブルの作成

続いてルートテーブルを作成し、作成したルートテーブルを作成したサブネットと関連付けます。network.tfファイルのサブネットの下の行へ、以下のコードを記述します。

# network.tf
# Route table
resource "aws_route_table" "rtb" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name    = "${var.project}-${var.environment}-rtb"
    Project = var.project
    Env     = var.environment
  }
}

# Route tableと subnetの関連付け
resource "aws_route_table_association" "public_rtb" {
  route_table_id = aws_route_table.rtb.id
  subnet_id      = aws_subnet.public.id
}

aws_route_tableのvpc_id = aws_vpc.main.idでは、VPCを作成した時点で払い出されるVPCのIDを参照しています。こうすることで、作成したmainというVPCとルートテーブルを紐づけることができます。

aws_route_table_associationでは、ルートテーブルを作成した時点で払い出されるIDと作成したサブネットのIDを参照しています。ここまでをマネジメントコンソールで考えてみると、以下の画像のようになります。

インターネットゲートウェイの作成

続いてインターネットゲートウェイ(以降IGW)をVPCへアタッチするためのコードを記述していきます。あわせてルートテーブルで通信する宛先を指定します。

# network.tf
# Internet Gateway
resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name    = "${var.project}-${var.environment}-igw"
    Project = var.project
    Env     = var.environment
  }
}

# Route tableとIGWの関連付け
resource "aws_route" "rtb_igw_route" {
  route_table_id         = aws_route_table.rtb.id
  destination_cidr_block = "0.0.0.0/0"
  gateway_id             = aws_internet_gateway.igw.id
}

aws_internet_gatewayリソースで作成したVPCのIDを参照しIGWをアタッチします。

aws_routeリソースで、作成したルートテーブルのIDとIGWのIDを参照し、destination_cidr_blockで宛先をインターネットへ向けています。

セキュリティグループの作成

次にセキュリティグループを作成します。network.tfファイルに全て記述しても問題ありませんが、冗長になってしまうことを考えて今回はsecurity_group.tfファイルを作成し管理することにします。

# Security Group
resource "aws_security_group" "sg" {
  name        = "${var.project}-${var.environment}-sg"
  description = "security group"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  tags = {
    Name    = "${var.project}-${var.environment}-sg"
    Project = var.project
    Env     = var.environment
  }
}

aws_security_groupリソースでセキュリティグループを作成します。

こちらも作成したVPCのIDを参照し、ingressブロックでインバウンド、egressブロックでアウトバウンドのトラフィックを制御します。今回はssh接続を行うため、ingressで22番ポートを指定します。

対してegressでは全てのアウトバウンドを許可するため0を指定し、protocolでは全ての通信を表す-1を指定します。

マネジメントコンソールからセキュリティグループを作成する場合、アウトバウンドの通信はデフォルトで許可されるようになっているため記述は必要ありません。

一方Terraformでは、egressとしてアウトバウンドの設定を記述する必要があり、この設定をせずにセキュリティグループを作成するとパッチの適用などの外向けの通信が許可されないため注意が必要です。

コードの記述は完了したため、terraform planを実行し、問題がなければapplyします。

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

ここまででVPC、ルートテーブル、セキュリティグループの作成が完了しました。次はEC2インスタンスの作成、ssh接続を行います。

EC2の作成とssh接続

はじめに、EC2インスタンスを作成してssh接続をする際に必要なキーペアを作成します。以下のコマンドでキーペアを作成します。

$ ssh-keygen -t rsa -f ec2-keypair

-fオプションでec2-keypairという名前で作成しました。このままではカレントディレクトリにキーペアが生成されるため、mvコマンドで.sshフォルダへ移動させます。

次に、EC2インスタンスを作成する際に必要なAMI IDを取得します。今回この作業には、DataSourceと呼ばれる機能を使ってIDを取得します。この機能を使うことで、Terraformの外側にある情報を取得して参照することができます。data.tfファイルを作成し、コードを記述します。

aws_amiに関しては公式ドキュメントを参照ください。

# data.tf
data "aws_ami" "amazonlinux" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "architecture"
    values = ["x86_64"]
  }

  filter {
    name   = "root-device-type"
    values = ["ebs"]
  }

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  filter {
    name   = "block-device-mapping.volume-type"
    values = ["gp2"]
  }
}

こちらでは、most_recentをtrueとすることで、最新のAMIを取得するよう指定しています。その他はfilterでAMIに必要な項目を一つ一つ絞り込むことができ、作成したいイメージの種類などを詳細に指定することができます。

続いてEC2インスタンスを作成します。ec2.tfファイルを作成し、コードを記述します。

# ec2.tf
# EC2 keypair
resource "aws_key_pair" "ssh_key" {
  key_name   = "ssh_key"
  public_key = file("~/.ssh/ec2-keypair.pub")
}
# EC2 instance
resource "aws_instance" "main" {
  ami                         = data.aws_ami.amazonlinux.id
  instance_type               = "t3.micro"
  subnet_id                   = aws_subnet.public.id
  associate_public_ip_address = true
  vpc_security_group_ids      = [aws_security_group.sg.id]
  key_name                    = aws_key_pair.ssh_key.key_name

  tags = {
    Name    = "${var.project}-${var.environment}-ec2"
    Project = var.project
    Env     = var.environment
  }
}

aws_key_pairリソースでは、AWS側に登録する公開鍵を指定します。Terraformの組み込み関数であるfile関数を使用することで、別のファイルに存在する内容を読み込むことができます。

aws_instanceリソースでEC2インスタンスを作成します。amiで先ほど作成したdata.tfファイルのamiIDを取得し、サブネットIDやインスタンスタイプなどを指定します。

key_nameでは、aws_key_pairリソースで作成したキーペア名を参照しています。

完了したら、planを実行し、エラー等がなければapplyを実行します。

EC2インスタンスを作成できたのが確認できたので、sshで接続します。

$ ssh -i ~/.ssh/ec2-keypair ec2-user@54.178.175.72
The authenticity of host '54.178.175.72 (54.178.175.72)' can't be established.
~省略~

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/
4 package(s) needed for security, out of 14 available
Run "sudo yum update" to apply all updates.
# 外向けの通信が許可されているか確認してみる
[ec2-user@ip-10-0-1-201 ~]$ sudo yum update
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
amzn2-core
~省略~
Replaced:
  grub2.x86_64 1:2.06-9.amzn2.0.1          grub2-tools.x86_64 1:2.06-9.amzn2.0.1

Complete!

無事ssh接続が完了し、updateコマンドも完了したため外部との接続も確認することができました。

まとめ

今回はTerraformのインストールから、Terraformを使ってEC2インスタンスの作成までを実践しました。マネジメントコンソールを使用してポチポチする感覚とは違い、ドキュメントを確認しながら作成していく面白さがあります。

作成するまでの時間と構文を学習して理解する時間はかかりますが、このコードをテンプレート化として使用し、内容を一部変更するだけで違った環境の構築ができるというのは非常にメリットがあると感じています。

またTerraformのコマンド操作に慣れてきたらaliasに登録して、全てのコマンドを叩かないようにするなど工夫していくのも面白いのではないでしょうか？

【番外編】USBも知らなかった私が独学でプログラミングを勉強してGAFAに入社するまでの話

IT未経験者必見 USBも知らなかった私が独学でプログラミングを勉強してGAFAに入社するまでの話

プログラミング塾に半年通えば、一人前になれると思っているあなた。それ、勘違いですよ。「なぜ間違いなの？」「正しい勉強法とは何なの？」ITを学び始める全ての人に知って欲しい。そう思って書きました。是非読んでみてください。

「フリーランスエンジニア」

近年やっと世間に浸透した言葉だ。ひと昔まえ、終身雇用は当たり前で、大企業に就職することは一種のステータスだった。しかし、そんな時代も終わり「優秀な人材は転職する」ことが当たり前の時代となる。フリーランスエンジニアに高価値が付く現在、ネットを見ると「未経験でも年収400万以上」などと書いてある。これに釣られて、多くの人がフリーランスになろうとITの世界に入ってきている。私もその中の1人だ。数年前、USBも知らない状態からITの世界に没入し、そこから約2年間、毎日勉学を行なった。他人の何十倍も努力した。そして、企業研修やIT塾で数多くの受講生の指導経験も得た。そこで私は、伸びるエンジニアとそうでないエンジニアをたくさん見てきた。そして、稼げるエンジニア、稼げないエンジニアを見てきた。

「成功する人とそうでない人の違いは何か？」

私が出した答えは、「量産型エンジニアか否か」である。今のエンジニア市場には、量産型エンジニアが溢れている！！ここでの量産型エンジニアの定義は以下の通りである。

比較的簡単に学習可能なWebフレームワーク（WordPress, Rails）やPython等の知識はあるが、ITの基本概念を理解していないため、単調な作業しかこなすことができないエンジニアのこと。

多くの人がフリーランスエンジニアを目指す時代に中途半端な知識や技術力でこの世界に飛び込むと返って過酷な労働条件で働くことになる。そこで、エンジニアを目指すあなたがどう学習していくべきかを私の経験を交えて書こうと思った。続きはこちらから、、、、