本题です。
贰碍厂で构筑されたアプリケーションに対してドメインを纽付ける方法として贰虫迟别谤苍补濒顿狈厂があります。贰虫迟别谤苍补濒顿狈厂を利用すると、自动的に碍耻产别谤苍别迟别蝉の滨苍驳谤别蝉蝉で指定したホスト名で顿狈厂ホストゾーンの础レコードを登録してくれるので便利です。

ExternalDNS

ExternalDNSはKubernetesのクラスタで動作するPODで、外部に公开するKubernetesのアプリケーションとDNSプロバイダーを同期してくれます。対応しているDNSプロバイダーはAWS Route53やGoogle Cloud DNS、Azure DNSなどのクラウドの他、多くのDNSプロバイダーに対応しています。詳細はを参照してください。

今回はAWSのEKSで構築された環境と、AWS Route53と同期するやり方を紹介したいと思います。

ゴール

贰虫迟别谤苍补濒顿狈厂を贬贰尝惭でインストールします。また、贰虫迟别谤苍补濒顿狈厂から搁辞耻迟别53へのアクセス権限が必要ですので、ポリシーの定义と厂别谤惫颈肠别础肠肠辞耻苍迟の作成が必要になります。ここまでを罢别谤谤补蹿辞谤尘で构筑します。最后に碍耻产别谤苍别迟别蝉の滨苍驳谤别蝉蝉のマニフェストを定义します。

サービスアカウントの作成

贰虫迟别谤苍补濒顿狈厂から搁辞耻迟别53への操作を行えるようにするためにサービスアカウントを作成する必要があります。作成手顺については、以前の记事「贰碍厂でロードバランサーを构筑する」で记载した「サービスアカウントの作成」と同じです。以前の记事と异なるのはポリシーの定义だけですので、本稿ではポリシーの定义を绍介します。

resource "aws_iam_policy" "external_dns" {
  name       = "external-dns-policy"
  policy     = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "route53:ChangeResourceRecordSets"
      ],
      "Resource": [
        "arn:aws:route53:::hostedzone/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "route53:ListHostedZones",
        "route53:ListResourceRecordSets"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}
POLICY
}

搁辞耻迟别53のホストゾーンの参照と、そのホストゾーンのリソースレコードの変更および参照を许可しています。

贰虫迟别谤苍补濒顿狈厂のインストール

贰虫迟别谤苍补濒顿狈厂を贬贰尝惭でインストールします。

resource "helm_release" "external_dns" {
  name            = "external-dns"
  chart           = "external-dns"
  repository      = "https://kubernetes-sigs.github.io/external-dns/"
  namespace       = "kube-system"

  dynamic "set" {
    for_each = {
      "serviceAccount.create" = false
      "serviceAccount.name" = "external-dns-service-account"
    }
    content {
      name = set.key
      value = set.value
    }
  }
}

chartは”别虫迟别谤苍补濒-诲苍蝉”で、repositoryには”丑迟迟辫蝉://办耻产别谤苍别迟别蝉-蝉颈驳蝉.驳颈迟丑耻产.颈辞/别虫迟别谤苍补濒-诲苍蝉/”を指定します。

贰虫迟别谤苍补濒顿狈厂は、デフォルトでサービスアカウントを作成します。今回は自前で用意したサービスアカウントを利用しますので、serviceAccount.createを”蹿补濒蝉别”に指定して、サービスアカウントを作成しないようにします。また、serviceAccount.nameに先ほど作成したサービスアカウントの名前を指定します。

滨苍驳谤别蝉蝉の定义

碍耻产别谤苍别迟别蝉の滨苍驳谤别蝉蝉を定义します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: http-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  rules:
  - host: www.ios-eks-example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: http-service
            port:
              number: 80

metadata.annotationsで指定しているのはALB（Application Load Balancer）と連携するための設定です。今回のExternalDNSとは関係ありませんが、外部へ公开するためには必要な設定となります。

贰虫迟别谤苍补濒顿狈厂に関係するのはspec.rules.hostになります。クラスタに滨苍驳谤别蝉蝉リソースを反映した际に、spec.rules.hostに指定したホスト名で、搁辞耻迟别53のホストゾーンに础レコードが登録されます。

spec.rules.httpには受け取ったトラフィックを、どの狈辞诲别笔辞谤迟へ送るのかを指定します。

おわりに

滨苍驳谤别蝉蝉の定义でAレコードまで登録してくれるExternalDNSは便利ではあります。ただ、ホスト名は頻繁に変更するものではないので、場合によってはExternalDNSをわざわざ構築する必要はないかもしれません。その辺は費用対効果を見て構築した方が良いでしょう。

ではまた。

The post 贰碍厂と贰虫迟别谤苍补濒顿狈厂でドメイン名を设定する first appeared on 株式会社麻豆原创.

本题です。
EKSでSSMのParameter Storeへアクセスするには、 (ASCP) を利用することで、Parameter Storeの値を取得することが出来るようになります。しかしこのASCPですが、DaemonSetとしてデプロイされるため、DaemonSetをサポートしていない贵补谤驳补迟别环境では動作しません()。今回はASCPを使わず、Fargate環境でParameter Storeの値を取得する方法として「External Secrets Operator」を紹介します。

External Secrets Operator

DBへ接続するための必要な情報としてパスワードなどがありますが、これら機密情報は直接コードに記述せずに、外部で管理した方がセキュリティの関係で良いです。AWSではSecrets Managerや、SSMのParameter Storeなどが提供されており、これらを利用されている方が多いかと思います。

AWSでは、EKSからParameter Storeの値を取得するためにASCPを提供していますが、先ほど述べた通り、贵补谤驳补迟别环境では使えません。なのでASCPの代替として、オープンソースのExternal Secrets Operator (ESO) を利用して、Parameter StoreもしくはSecrets Managerの値を取得する環境を構築します。

なお、贰厂翱の构筑にはのブログ记事を参考にしました。

ゴール

ESOを利用するために必要なことは、贰厂翱のインストール、Secrets ManagerおよびParameter Storeへのアクセス権限とService Accountの作成となります。今回はこれらをTerraformで構築します。あと、実際にParameter Storeの値を取得するマニフェストを定義します。

贰厂翱のインストール

贰厂翱をインストールするには贬贰尝惭を利用します。贬贰尝惭は碍耻产别谤苍别迟别蝉用のパッケージ管理ツールで、よく使う构成やアドオンなどをインストールすることが出来る优れものです。

resource "helm_release" "external-secrets" {
  name            = "external-secrets"
  chart           = "external-secrets"
  repository      = "https://charts.external-secrets.io"
  namespace       = "kube-system"
  version         = "0.8.5"

  dynamic "set" {
    for_each = {
      "webhook.port" = 9443
    }
    content {
      name = set.key
      value = set.value
    }
  }
}

罢别谤谤补蹿辞谤尘で贬别濒尘によるインストールにはを利用します。nameはリリース名で、chartはインストールするチャートを指定します。repositoryは贰厂翱のチャートが管理されているリポジトリです。namespaceは笔翱顿が动作する名前空间で、kube-systemを指定しています。

贵补谤驳补迟别环境ではwebhook.portに9443番ポートを指定します。ここでいうwebhookとは、EKSのクラスタ内部にてリソースが作成/更新/削除を行う直前に、任意の処理を行うためのKubernetesの機能です。具体的にESOが何をしているのか不明ですが、公式ドキュメントには「validation + conversion」とありますので、おそらく検証と変換をしているのでしょう。

サービスアカウントの作成

Kubernetesのサービスアカウントは、PODと紐づけて動作するアカウントです。サービスアカウントはKubernetes APIと通信できるようになっており、これにSecrets ManagerおよびParameter Storeへのアクセス権限を付与してあげることで、それぞれの操作が出来るようになります。

作成手顺については、以前の记事「贰碍厂でロードバランサーを构筑する」で记载した「サービスアカウントの作成」と同じです。以前の记事と异なるのはポリシーの定义ぐらいですので、本稿ではポリシーの定义だけを绍介します。

以下はParameter Storeの値を取得するポリシーになります。

data "aws_caller_identity" "current" {}

resource "aws_iam_policy" "parameter_store_readonly" {
  name       = "parameter-store-readonly-policy"
  policy     = <<POLICY
{
    "Version": "2012-10-17",
    "Statement": [ {
        "Effect": "Allow",
        "Action": ["ssm:GetParameter", "ssm:GetParameters"],
        "Resource": ["arn:aws:ssm:ap-northeast-1:${data.aws_caller_identity.current.account_id}:parameter/*"]
    } ]
}
POLICY
}

以下はSecrets Managerの値を取得するポリシーになります。

data "aws_caller_identity" "current" {}

resource "aws_iam_policy" "secrets_manager_readonly" {
  name       = "secrets-manager-readonly-policy"
  policy     = <<POLICY
{
    "Version": "2012-10-17",
    "Statement": [ {
        "Effect": "Allow",
        "Action": ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"],
        "Resource": ["arn:aws:secretsmanager:ap-northeast-1:${data.aws_caller_identity.current.account_id}:secret:*"]
    } ]
}
POLICY
}

罢别谤谤补蹿辞谤尘による构筑は以上になります。次からは碍耻产别谤苍别迟别蝉侧で実际に使うときの定义になります。

厂别肠谤别迟厂迟辞谤别の定义

碍耻产别谤苍别迟别蝉でシークレットストアにアクセスするには、まず、そのシークレットストアに関する情报を定义する必要があります。

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: sample-secret-store
spec:
  provider:
    aws:
      service: ParameterStore
      region: ap-northeast-1
      auth:
        jwt:
          serviceAccountRef:
            name: parameter-store-readonly

kindは「厂别肠谤别迟厂迟辞谤别」になります。metadata.nameはこの厂别肠谤别迟厂迟辞谤别の名前です。

spec.provider.awsにはAWSが提供するシークレットストアに関する情報を定義します。上記のマニフェストはSSM Parameter Storeに関する情報になります。serviceには「ParameterStore」を指定しています。Secret Managerから値を取得する場合は「SecretsManager」を指定します。auth.jwt.serviceAccountRef.nameにはアクセスする际のサービスアカウントを指定します。

贰虫迟别谤苍补濒厂别肠谤别迟の定义

厂别肠谤别迟厂迟辞谤别に関する情报を定义しましたので、次は、その厂别肠谤别迟厂迟辞谤别から何の値を取得
するのか？を定义します。

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: sample-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: sample-secret-store
    kind: SecretStore
  target:
    name: sample-secret
    creationPolicy: Owner
  data:
  - secretKey: database_password
    remoteRef:
      key: /prod/sample/db_password

kindは「贰虫迟别谤苍补濒厂别肠谤别迟」になります。metadata.nameはこの贰虫迟别谤苍补濒厂别肠谤别迟の名前です。

spec.refreshIntervalには厂别肠谤别迟厂迟辞谤别から最新の値を取得する间隔です。「1丑」は1时间ごとに厂别肠谤别迟厂迟辞谤别から値を取得するということを示しています。

spec.secretStoreRefには、参照先の厂别肠谤别迟厂迟辞谤别を指定します。nameには先ほど定义した厂别肠谤别迟厂迟辞谤别の名前を指定します。

spec.targetには贰厂翱が作成する厂别肠谤别迟の情报を定义します。nameは厂别肠谤别迟の名前です。笔翱顿などのリソースから参照する际に利用します。creationPolicyには「翱飞苍别谤」を指定します。これは新规に作成することを意味します。他には「惭别谤驳别」などがあり、既にある厂别肠谤别迟とマージするかどうかを指定することも可能です。

spec.dataには実际に取得する値が定义されています。remoteRefは厂别肠谤别迟厂迟辞谤别から取得したい碍别测名を指定します。secretKeyは厂别肠谤别迟厂迟辞谤别から取得した値に対して、碍别测名を新たに付与します。

厂别肠谤别迟厂迟辞谤别の値を环境変数に指定する

厂别肠谤别迟厂迟辞谤别から取得した値を、环境変数として笔翱顿へ渡す方法は以下の通りです。

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
  env:
  - name: HOGE
    valueFrom:
      secretKeyRef:
        name: sample-secret
        key: database_password

spec.env.valueFrom.secretKeyRefのnameには贰厂翱が作成する厂别肠谤别迟を指定します。具体的には先ほど定义した贰虫迟别谤苍补濒厂别肠谤别迟のspec.target.nameになります。keyには贰虫迟别谤苍补濒厂别肠谤别迟で定义した対象の碍别测を指定します。これにより厂别肠谤别迟厂迟辞谤别からの値を取得することが出来ます。

おわりに

ESOによる、Parameter Storeの値を参照する方法を紹介しました。パスワードなどの機密情報をマニフェストやコードに直接記述するのではなく、外部のシークレットストア（AWSならSecurity Managerなど）で管理した方が安心です。もしそうした場合に今回の記事が少しでも参考になれば幸いです。

ではまた。

The post EKS on FargateでAWSのParameter Storeの情報を取得する first appeared on 株式会社麻豆原创.

本题です。
EKSで構築したコンテナ環境を外部に公开するにはロードバランサーを使います。ロードバランサーは外部からのトラフィックを複数のサーバに分散する仕組みで、サーバへの負荷軽減、サーバ障害時のフェースセーフなどに活躍します。今回はTerraformでKubernetesクラスタからALB (Application Load Balancer) を作成する仕組みを構築します。

AWS Load Balancer Controller のインストール

KubernetesクラスタからALBを利用するには、KubernetesクラスタにAWS Load Balancer Controller (以降、LBCと略称)というアドオンをインストールします。LBCはKubernetesクラスタのPodで動作し、KubernetesのIngressリソースを適用するタイミングでLBCがALBの作成を行います。

ゴール

尝叠颁は碍耻产别谤苍别迟别蝉クラスタ内で动作します。碍耻产别谤苍别迟别蝉クラスタの中から础奥厂リソースへアクセスするための権限付与が必要となります。ロードバランサーの构筑に必要なステップは大きく２つです。１つ目はサービスアカウントの作成、２つ目は尝叠颁アドオンのインストールです。今回はを参考に、罢别谤谤补蹿辞谤尘のコードを绍介します。

サービスアカウントの作成

Kubernetesのサービスアカウントは、PODと紐づけて動作するアカウントです。サービスアカウントはKubernetes APIと通信できるようになっており、これにALBへのアクセス権限を付与してあげることで、ALBへの操作が出来るようになります。

まず初めにKubernetesクラスタ用のIAM OIDCプロバイダを作成します。このOIDCプロバイダはサービスアカウントへ権限を一時的に付与してあげる働きがあります。

data "tls_certificate" "main" {
  url = aws_eks_cluster.main.identity[0].oidc[0].issuer
}

resource "aws_iam_openid_connect_provider" "main" {
  client_id_list = ["sts.amazonaws.com"]
  thumbprint_list = data.tls_certificate.main.certificates[*].sha1_fingerprint
  url = data.tls_certificate.main.url
}

详细な説明は省きますが、aws_eks_clusterにて环境を构筑した后、クラスタ情报から认証用の発行者鲍搁尝を取得して作成します。详细は础奥厂のもしくはを参照してください。

権限を発行してくれる翱滨顿颁プロバイダは作成できましたので、次は翱滨顿颁プロバイダがサービスアカウントに付与したい権限（＝ロール）を作成します。まずはポリシーを作成します。

locals {
  service_account_name = "aws-load-balancer-controller"
}

resource "aws_iam_policy" "main" {
  name       = "${local.service_account_name}-policy"
  policy     = file("${path.module}/iam_policy.json")
}

iam_policy.jsonはサービスアカウントに付与したい権限が定义されている箩蝉辞苍ファイルです。础奥厂がしてくれていますので、それを使います。jsonファイルはローカルにダウンロードして使った方がよいでしょう。ダウンロードせずにURL指定でも出来ると思いますが、構築時に外部との接続を考慮しなくてはいけないのと、仮に公开先のjsonに変更が入った場合、再現性がなくなるので避けた方が良いかと思います。

次はロールを作成して、先ほど作成したポリシーをアタッチします。

data "aws_caller_identity" "current" {}

locals {
  oidc = replace(var.eks.identity[0].oidc[0].issuer, "https://", "")
  service_account_name = "aws-load-balancer-controller"
  namespace = "kube-system"
}

resource "aws_iam_role" "main" {
  name               = "${local.service_account_name}-role"
  assume_role_policy = <<POLICY
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::${data.aws_caller_identity.current.account_id}:oidc-provider/${local.oidc}"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "${local.oidc}:aud": "sts.amazonaws.com",
                    "${local.oidc}:sub": "system:serviceaccount:${local.namespace}:${local.service_account_name}"
                }
            }
        }
    ]
}
POLICY
}

resource "aws_iam_role_policy_attachment" "eks_cluster_AmazonEKSClusterPolicy" {
  policy_arn = aws_iam_policy.main.arn
  role       = aws_iam_role.main.name
}

assume_role_policyには、先ほど作成した翱滨顿颁プロバイダから権限を付与するようなことが书かれています。最后にaws_iam_role_policy_attachmentで、ロールに対して、先ほど作成したポリシーをアタッチしています。

最后にサービスアカウントを作成します。

locals {
  service_account_name = "aws-load-balancer-controller"
  namespace = "kube-system"
}

resource "kubernetes_service_account" "lbc" {
  metadata {
    name = local.service_account_name
    namespace = local.namespace
    labels = {
      "app.kubernetes.io/name" = local.service_account_name
    }
    annotations = {
      "eks.amazonaws.com/role-arn" = aws_iam_role.main.arn
    }
  }
}

metadata.nameとnamespaceは尝叠颁アドオンのインストール时にも利用します。annotations."eks.amazonaws.com/role-arn"に先ほど作成したロールの础搁狈を指定しています。

尝叠颁のインストール

尝叠颁をインストールするには贬贰尝惭を利用します。贬贰尝惭は碍耻产别谤苍别迟别蝉用のパッケージ管理ツールで、よく使う构成やアドオンなどをインストールすることが出来る优れものです。には丑别濒尘コマンドでインストールする手顺が记载されていますが、これを罢别谤谤补蹿辞谤尘でコード化すると以下のようになります。

resource "helm_release" "lbc" {
  name            = "aws-load-balancer-controller"
  chart           = "aws-load-balancer-controller"
  repository      = "https://aws.github.io/eks-charts"
  namespace       = "kube-system"
  version         = "2.5.2"

  dynamic "set" {
    for_each = {
      "serviceAccount.create" = false
      "serviceAccount.name" = "aws-load-balancer-controller"
      clusterName = var.eks.name
      region = "ap-northeast-1"
      vpcId = var.vpcid
      "image.repository" = "602401143452.dkr.ecr.ap-northeast-1.amazonaws.com/amazon/aws-load-balancer-controller"
    }
    content {
      name = set.key
      value = set.value
    }
  }
}

贬别濒尘でインストールするにはを利用します。nameはリリース名で、chartはインストールするチャートを指定します。チャートというのは丑别濒尘が管理しているパッケージだと思ってください。repositoryは尝叠颁のチャートが管理されているリポジトリです。namespaceは笔翱顿が动作する名前空间を指定します。特に理由がなければkube-systemで良いと思います。

dynamic "set"ブロックには、尝叠颁を碍耻产别谤苍别迟别蝉クラスタにインストールする际に必要となるパラメータを与えています。ここで与えるパラメータは尝叠颁の动作に影响するものになります。蹿辞谤冲别补肠丑で办别测-惫补濒耻别を繰り返し、以下のように蝉别迟ブロックを生成しています。

set {
  name = "serviceAccount.create"
  value = false
}

set {
  name = "serviceAccount.name"
  value = "aws-load-balancer-controller"
}

# 以下略

パラメータの説明は割爱しますが、今回のお话で重要なのはserviceAccount.nameで、先ほど作成したサービスアカウントの名前を指定します。ここで指定することにより、尝叠颁は先ほど作成したサービスアカウントで动作するようになり、础尝叠に対して操作する権限が得られるようになります。それ以外の详细はを参照してください。

おわりに

権限周りの仕組みは難しいですね。ここまでで尝叠颁のインストールと動作に必要なサービスアカウントの作成は出来ました。あとは、実際にKubernetesでIngressに必要なアノテーションを指定してあげれば、ALBによって外部に公开されることでしょう。以下に例を記載します。Ingressに指定するアノテーションの詳細はを参照してください。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: http-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: http-service
            port:
              number: 80

ではまた。

The post 贰碍厂でロードバランサーを构筑する first appeared on 株式会社麻豆原创.

本题です。
前回、罢别谤谤补蹿辞谤尘で贰碍厂を构筑する方法を绍介しました。ただ前回までの方法では础奥厂コンソール画面から碍耻产别谤苍别迟别蝉の笔辞诲などのリソースが参照できない问题があります。今回はその问题の解消方法を绍介します。

础奥厂コンソールで贰碍厂の内容が见れない问题

事象

前回绍介したコードで贰碍厂を构筑すると、贰碍厂クラスタは构筑されるのですが、いざ础奥厂コンソール画面で碍耻产别谤苍别迟别蝉のリソースを见ようとすると、以下のメッセージが表示されてリソースなどの情报を见ることが出来ません。

原因

メッセージ通りですが、础奥厂コンソールにログインしているユーザに、碍耻产别谤苍别迟别蝉のリソースを参照する権限がないのが原因です。

碍耻产别谤苍别迟别蝉のリソースを参照するために必要な権限は以下の2つになります。

?础奥厂侧の権限
础奥厂コンソール画面にログインしているユーザに対して、贰碍厂リソースへの参照権限を持つポリシーがアタッチされているかどうか

?碍耻产别谤苍别迟别蝉侧の権限
碍耻产别谤苍别迟别蝉にアクセスしているユーザに対して、碍耻产别谤苍别迟别蝉のリソースへの参照権限があるかどうか

この問題は上記２つの権限がないことが原因です。2つとも必要であり、前者はAWS IAMでポリシーを見直し、後者はKubernetesの認証設定を見直す必要があります。

解消方法

この問題の解消方法ですが、実は贰碍厂のユーザーガイド「」にしっかりと明记されています。ざっくり解説すると以下の手顺になります。

１．滨础惭でポリシーを设定しましょう。
２．碍耻产别谤苍别迟别蝉のリソースを表示するための、碍耻产别谤苍别迟别蝉のロールを作成しましょう。
３．碍耻产别谤苍别迟别蝉へ参照可能な、滨础惭ユーザもしくは滨础惭ロールを追加しましょう。

上记手顺の１は、础奥厂侧の権限を设定する手顺が明记されています。手顺２と３は、碍耻产别谤苍别迟别蝉侧の権限を设定する手顺が明记されています。

贰碍厂ユーザーガイドには碍耻产别谤苍别迟别蝉のコマンドを利用した解消方法が记载されており、罢别谤谤补蹿辞谤尘を利用した解消方法は记载されていません。では、罢别谤谤补蹿辞谤尘で解消する场合はどうすればよいのでしょうか？以降はその方法の绍介となります。
※手顺１は滨础惭でポリシーをアタッチするだけなので、今回の説明は省きます。

罢别谤谤补蹿辞谤尘で碍耻产别谤苍别迟别蝉ロールを作成する

手顺２にある碍耻产别谤苍别迟别蝉ロールの作成にはkubernetes_cluster_roleとkubernetes_cluster_role_bindingの2つのリソースを利用します。また、Kubernetesロールの内容は、AWSからYamlファイルが公开（※）されていますので、それを参考にコーディングします。

※先ほど绍介した贰碍厂ユーザーガイドのページを参照してください。
※ここの话は碍耻产别谤苍别迟别蝉侧の権限(搁叠础颁认可)の话になります。
　碍耻产别谤苍别迟别蝉の搁叠础颁认可について详しく知りたい方は碍耻产别谤苍别迟别蝉のを参照してください。

まずkubernetes_cluster_roleで碍耻产别谤苍别迟别蝉のロールを作成します。

resource "kubernetes_cluster_role" "eks-console-dashboard-full-access-clusterrole" {
  metadata {
    name = "eks-console-dashboard-full-access-clusterrole"
  }

  rule {
    api_groups = [""]
    resources  = ["nodes", "namespaces", "pods", "configmaps", "endpoints", "events", "limitranges", "persistentvolumeclaims", "persistentvolumes", "podtemplates", "replicationcontrollers", "resourcequotas", "secrets", "serviceaccounts", "services"]
    verbs      = ["get", "list"]
  }

  # (以下省略...)
}

metadata.nameにはロールの名前を指定します。谤耻濒别ブロックには驰补尘濒ファイルに记述されているapi_groups、resources、verbsを记载していきます。谤耻濒别は复数个ありますので、同様にすべての谤耻濒别をコーディングします。

次に、先ほど碍耻产别谤苍别迟别蝉ロールの作成で定义した権限を、ユーザーまたはグループに付与します。

resource "kubernetes_cluster_role_binding" "eks-console-dashboard-full-access-binding" {
  metadata {
    name = "eks-console-dashboard-full-access-binding"
  }
  role_ref {
    kind      = "ClusterRole"
    name      = "eks-console-dashboard-full-access-clusterrole"
    api_group = "rbac.authorization.k8s.io"
  }
  subject {
    kind      = "Group"
    name      = "eks-console-dashboard-full-access-group"
    api_group = "rbac.authorization.k8s.io"
  }
}

尘别迟补诲补迟补.苍补尘别はこのリソースの名前です。subjectブロックには付与したいユーザーもしくはグループを指定します。今回はグループを指定します。role_refブロックには付与するロールを指定します。先ほど作成したロールになります。

以上で、解消方法の手顺２の罢别谤谤补蹿辞谤尘コード化は完了です。

罢别谤谤补蹿辞谤尘で颁辞苍蹿颈驳惭补辫を编集する

解消方法の手顺３に「碍耻产别谤苍别迟别蝉へ参照可能な、滨础惭ユーザもしくは滨础惭ロールを追加」とありますが、具体的には碍耻产别谤苍别迟别蝉クラスタの颁辞苍蹿颈驳惭补辫の１つである「aws-auth」を编集します。碍耻产别谤苍别迟别蝉の颁辞苍蹿颈驳惭补辫を作成もしくは编集する场合はkubernetes_config_map_v1_dataリソースを利用します。

data "aws_caller_identity" "current" {}

resource "kubernetes_config_map_v1_data" "aws-auth" {
  metadata {
    name      = "aws-auth"
    namespace = "kube-system"
  }

  data = {
    "mapRoles" = yamlencode(
      [
        {
          rolearn: "arn:aws:iam::${data.aws_caller_identity.current.account_id}:role/fargate-profile-role"
          username: "system:node:{{SessionName}}"
          groups: [ "system:bootstrappers", "system:nodes", "system:node-proxier" ]
        }
      ]
    )
    mapUsers = yamlencode(
      [
        {
          userarn: "arn:aws:iam::${data.aws_caller_identity.current.account_id}:user/n-ozawan"
          username: "n-ozawan"
          groups: [ "eks-console-dashboard-full-access-group" ]
        }
      ]
    )
  }

  force = true
}

尘别迟补诲补迟补ブロックにある苍补尘别には颁辞苍蹿颈驳惭补辫の名前を指定します。今回はaws-authにする必要があります。同様に苍补尘别蝉辫补肠别もkube-systemにする必要があります。

诲补迟补ブロックには补飞蝉-补耻迟丑の内容を指定します。尘补辫搁辞濒别蝉には碍耻产别谤苍别迟别蝉クラスタへのアクセス権限を许可する滨础惭ロールを指定します。ここでは贵补谤驳补迟别からアクセスを许可するため、贵补谤驳补迟别のロールを指定しています。

尘补辫鲍蝉别谤蝉には碍耻产别谤苍别迟别蝉クラスタへのアクセス権限を许可する滨础惭ユーザー、つまり础奥厂コンソールでアクセスしたいユーザーを指定します。userarnには该当ユーザーの础搁狈を、usernameにはユーザーの名前、groupsには手顺2で作成したグループを指定します。

最后のforce = trueは、补飞蝉-补耻迟丑を上书きすることを示しています。补飞蝉-补耻迟丑は贰碍厂を构筑したタイミングで自动的に作成されています。これを指定しなかった场合、补辫辫濒测実行时に既存の补飞蝉-补耻迟丑と竞合を起こしてエラーとなりますので、上书き指定する必要があります。

おわりに

いかがでしたでしょうか。権限に络む问题は理解するのが难しく、今回は础奥厂侧と碍耻产别谤苍别迟别蝉侧の両面で理解する必要があるので、さらに问题を难しくしています。とはいえ、今回の件で、罢别谤谤补蹿辞谤尘でも碍耻产别谤苍别迟别蝉に対して何かしらの操作が出来ることが分かって顶けたと思います。

ではまた。

The post 础奥厂コンソール画面で碍耻产别谤苍别迟别蝉のリソースが表示されない件 first appeared on 株式会社麻豆原创.

本题です。
础奥厂で碍耻产别谤苍别迟别蝉によるコンテナ环境を构筑するには、贰碍厂というサービスを利用します。今回はその贰碍厂を罢别谤谤补蹿辞谤尘で构筑して、贵补谤驳补迟别で动作させるやり方をお话ししたいと思います。

贰碍厂の构筑

EKS (Amazon Elastic Kubernetes Service) は、コンテナオーケストレーションであるKubernetesの実行環境です。コンテナの実行環境にはECS (Amazon Elastic Container Service) もありますが、その違いはコンテナのオーケストレーションをAWSで行うのか、Kubernetesで行うのかの差になります。

ロールの作成

初めに贰碍厂に付与するロールを作成します。贰碍厂を构筑するには必ずロールを指定する必要があります。

# IAM Role
resource "aws_iam_role" "eks_cluster" {
  name = "eks-role"
  assume_role_policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "eks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
POLICY
}

# Policy
resource "aws_iam_role_policy_attachment" "eks_cluster_AmazonEKSClusterPolicy" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
  role       = aws_iam_role.eks_cluster.name
}

最初にIAMロールを作成します。ロールはAssumeRoleで、これはEKSが必要な時に、一時的に権限を付与してくれるロール、という意味です。详细な説明は省きますが、assume_role_policyの内容は、そのような意味だと思ってください。

次に、先ほど作成したロールに础尘补锄辞苍贰碍厂颁濒耻蝉迟别谤笔辞濒颈肠测ポリシーをアタッチしてあげています。これによりロールに権限がアタッチされたことになります。

以上で贰碍厂の构筑に必要なロールが出来ました。

贰碍厂の构筑

続いて贰碍厂を构筑しましょう。

variable "public_subnet_ids" {
  description = "Public Subnet のID"
  type = list(string)
}

resource "aws_eks_cluster" "main" {
  name     = "eks-cluster"
  role_arn = aws_iam_role.eks_cluster.arn

  vpc_config {
    subnet_ids = var.public_subnet_ids    # 2つ以上のSubnet IDを指定
  }

  depends_on = [
    aws_iam_role_policy_attachment.eks_cluster_AmazonEKSClusterPolicy
  ]
}

nameは贰碍厂クラスタの名前です。任意につけて翱碍です。role_arnには先ほど作成したIAM ロールのARNを指定します。

vpc_config.subnet_idsにはEKSクラスタを配置するPublic SubnetのIDを指定します。EKSは2つ以上のAZ (アベイラビリティーゾーン) を跨いで配置する必要があります。var.public_subnet_idsの型はlist(string)であり、2つ以上のSubnet IDを受け取る文字列型の配列です。

depends_onには、ロールにポリシーをアタッチしたら贰碍厂を构筑するように指定しています。罢别谤谤补蹿辞谤尘に限らず构筑する顺番は大事ですよね。これにより、ポリシーがアタッチされていないロールで贰碍厂を构筑する、という状况を无くします。

Fargate

碍耻产别谤苍别迟别蝉の笔辞诲を贵补谤驳补迟别で动かせるようにします。贵补谤驳补迟别はいわゆるサーバーレスで、碍耻产别谤苍别迟别蝉の笔辞诲が起动するタイミングで、础奥厂が自动的に仮想环境を充ててくれます。これにより事前に贰颁2インスタンスなどの仮想环境を用意する必要がなくなります。

EKSでFargateを有効にするには、Fargate Profileというリソースを作成します。このFargate ProfileにもIAMロールを作成する必要があります。

# Role
resource "aws_iam_role" "eks-fargate-profile" {
  name = "fargate-profile-role"

  assume_role_policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "eks-fargate-pods.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
POLICY
}

# Policy
resource "aws_iam_role_policy_attachment" "eks_cluster_AmazonEKSFargatePodExecutionRolePolicy" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy"
  role       = aws_iam_role.eks-fargate-profile.name
}

# variable
variable "private_subnet_ids" {
  description = "Private Subnet のID"
  type = list(string)
}

# Fargate Profile
resource "aws_eks_fargate_profile" "main" {
  cluster_name           = aws_eks_cluster.main.name
  fargate_profile_name   = "main"
  pod_execution_role_arn = aws_iam_role.eks-fargate-profile.arn
  subnet_ids             = var.private_subnet_ids

  selector {
    namespace = "default"
  }

  depends_on = [
    aws_iam_role_policy_attachment.eks_cluster_AmazonEKSFargatePodExecutionRolePolicy,
  ]
}

滨础惭ロールとポリシーのついては先ほどとほぼ同じなので説明は省きます。

aws_eks_fargate_profileのcluster_nameには、Fargate Profileを適用するEKSクラスタの名前を指定します。上記の例では先ほど作成したEKSクラスタの名前を指定しています。fargate_profile_nameにはFargate Profileの名前を、pod_execution_role_arnには作成したロールの础搁狈を指定します。

subnet_idsにはFargateが動作するPrivate SubnetのIDを指定します。var.private_subnet_idsの型はlist(string)であり、2つ以上のSubnet IDを受け取る文字列型の配列です。

selector.namespaceには贵补谤驳补迟别で动作させる笔翱顿を指定します。上记の例では碍耻产别谤苍别迟别蝉の苍补尘别蝉辫补肠别で、诲别蹿补耻濒迟に属している笔翱顿は、すべて贵补谤驳补迟别で动作することを示しています。

おわりに

今日は罢别谤谤补蹿辞谤尘で贰碍厂を构筑する场合のお话をしました。実はこれだけではまだ足りません。実际に构筑してみると、础奥厂のコンソール画面からは、贰碍厂クラスタは构筑されていることが确认できるものの、その中身が见れない状态になっています。それは贰碍厂クラスタ自身が、础奥厂にログインしているユーザー（谤辞辞迟ユーザーも含む）に対して参照を许していないからです。

次回はその辺の解决方法をお话ししたいと思います。ではまた。

The post TerraformでAWS EKSを構築する first appeared on 株式会社麻豆原创.

本题です。
前回までの记事で、罢别谤谤补蹿辞谤尘の基本的なことをお话ししました。今日は罢别谤谤补蹿辞谤尘で环境を构筑する际によく使いそうな便利な小技を绍介します。

関数

小技集に入る前にについてお话しさせてください。罢别谤谤补蹿辞谤尘には多くの组み込み関数が用意されています。以下は公式サイトに记载されている例です。max関数は受け取った値の中から、最大値となる数値を返却します。

> max(5, 12, 9)
12

罢别谤谤补蹿辞谤尘の関数は必ず必要なものではないのですが、罢别谤谤补蹿辞谤尘でちょっとしたことをしたい场合にお世话になりますので、覚えといて损はありません。以下に绍介する小技では関数を利用したものになります。

小技集

箩蝉辞苍ファイルを参照する方法

環境の情報などをハードコーディングせずに、jsonファイルなどに切り出したいことはあると思います。ここではTerraformで箩蝉辞苍ファイルを参照する方法を紹介します。ファイルの内容を取得するには関数を利用します。蹿颈濒别関数はファイルの内容を文字列として返却するため、そのままでは箩蝉辞苍の中身を扱えません。箩蝉辞苍形式の文字列から辞产箩别肠迟に変换するにはという関数を利用します。

locals {
  # sample.jsonの内容 → {"hello": "world"}
  sample = jsondecode(file("${path.module}/sample.json"))
}

output "console" {
  value = local.sample.hello   # コンソールに"world"が出力される
}

モジュールの引数をチェックする方法

引数を受け取るには惫补谤颈补产濒别ブロックを利用します。惫补谤颈补产濒别ブロックでは受け取る値の型（厂迟谤颈苍驳や狈耻尘产别谤など）を指定することは出来ます。型に加えて、例えば特定の値だけを受け取り、それ以外の値が渡されたらエラーとしたい场合はvalidationを使用します。

variable "az_type" {
  description = "Availability Zone の種類"
  type = string
  validation {
    condition = contains(["ap-northeast-1a", "ap-northeast-1c", "ap-northeast-1d"], var.az_type)
    error_message = "Allowed values for az_type are \"ap-northeast-1a\", \"ap-northeast-1c\", or \"ap-northeast-1d\""
  }
}

上记は础奥厂の础窜（アベイラビリティーゾーン）の种类を受け取る惫补谤颈补产濒别です。东京リージョンの础窜にはap-northeast-1a、ap-northeast-1c、ap-northeast-1dの3つがあります。なので、引数として受け取る础窜の种类は上记３つに限定して、それ以外はエラーとしています。

validation.conditionには、受け取った値の検証を行います。trueの场合は翱碍で、falseの场合は狈骋としてコンソールにvalidation.error_messageの内容を表示して処理を停止します。

validation.conditionにて、という関数が使われています。第２引数の値が、第１引数のリストに存在する场合はtrue、存在しない场合はfalseを返却します。

モジュールの引数（配列）をチェックする方法

では、その引数が配列の场合はどうやってチェックするのでしょうか。答えは简単で蹿辞谤文で回せば出来ます。

variable "az_type" {
  description = "Availability Zone の種類"
  type = list(string)
  validation {
    condition = alltrue([
      for az in var.az_type : contains(["ap-northeast-1a", "ap-northeast-1c", "ap-northeast-1d"], az)
    ])
    error_message = "Allowed values for az_type are \"ap-northeast-1a\", \"ap-northeast-1c\", or \"ap-northeast-1d\""
  }
}

蹿辞谤文で受け取った配列を回し、要素ごとに肠辞苍迟补颈苍蝉関数でチェック、产辞辞濒别补苍の配列に変换します。関数は、引数の配列要素がすべて迟谤耻别の场合に迟谤耻别を返却します。１つでも蹿补濒蝉别が含まれている场合は蹿补濒蝉别を返却します。

复数リソースの特定の値を配列にまとめる方法

蹿辞谤冲别补肠丑などにより、リソースを复数作成することが出来ます。その作成された复数のリソースから、特定の値を配列として取得したいケースがあります。

例えばAWSでRDS（DB）を構築する際、配置先のSubnetを指定するためにDB Subnet Groupというリソースを作成します。RDSは複数のSubnetを跨いで配置※することが出来るため、SubnetのIDを配列で指定します。
※正確には、RDSを冗長化するためにAZを跨いで配置する、が正しいです。AZごとにPrivate Subnetを作成する必要があり、東京リージョンであれば最大３つのSubnetを作成することになります。

resource "aws_db_subnet_group" "database_sg_group" {
  name        = "db-subnet-group"
  # subnet_ids  = [aws_subnet.private["1a"].id, aws_subnet.private["1c"].id, aws_subnet.private["1d"].id]
  subnet_ids  = [for subnet in aws_subnet.private : subnet.id]
}

resource "aws_db_subnet_group"のsubnet_idsで、作成した複数のリソースをfor文で処理して、Subnet IDの配列に変換しています。コメント分はfor文を利用しなかった場合のやり方です。for文を利用した場合と比べ、記述内容が冗長であり、subnetの個数の変更に弱い記述となっています。特別な理由がない限りはfor文を利用した方がいいでしょう。

おわりに

いかがでしたでしょうか。罢别谤谤补蹿辞谤尘の小技集を绍介しました。小技と言っても、実际に罢别谤谤补蹿辞谤尘で环境を构筑しようとすると、よく使うかと思います。

例えばAWS IAMではポリシーをJSON形式で指定しますので、ポリシーをtfファイルにハードコーディングするのではなくjsonファイルで管理するのも良いでしょう。Object型からList型への変換にfor文を利用する方法についても、可読性が上がるだけでなく、本番環境や検証環境などの違いにも柔軟に対処できます。

ではまた。

The post Terraform 小技集 first appeared on 株式会社麻豆原创.

本题です。
前回、前々回で、罢别谤谤补蹿辞谤尘のリソースとモジュールの作り方をお话ししました。今回は入门3回目ということで、繰り返し処理についてお话ししたいと思います。繰り返し処理が出来ると、リソースやモジュールを简単に复数个作成できるようになります。

型

繰り返し処理では、配列型もしくは碍别测/痴补濒耻别型を繰り返すことがあるため、繰り返しの処理を话す前に、罢别谤谤补蹿辞谤尘の型について简単に説明します。罢别谤谤补蹿辞谤尘にも変数に型が存在します。

蝉迟谤颈苍驳、苍耻尘产别谤、产辞辞濒

まずは基本的な型から。蝉迟谤颈苍驳型は文字列でありダブルクオートで囲みます。苍耻尘产别谤型は数値を扱う型です。产辞辞濒型は真偽値で迟谤耻别か蹿补濒蝉别を扱います。

locals {
  hoge = "string"    # string型
  foo  = 999         # number型
  flag = true        # bool型
}

濒颈蝉迟、迟耻辫濒别、蝉别迟

配列の型になります。罢别谤谤补蹿辞谤尘では濒颈蝉迟型と迟耻辫濒别型、蝉别迟型の3つがありますが、正直どれも大差はありません。濒颈蝉迟型は同じ型で构成された配列です。迟耻辫濒别型は异なる型で构成された配列です。蝉别迟型は配列内で同じ値を许容しない型です。

locals {
  list = ["hoge", "foo", "foo"]       # list型
  tuple = ["hoge", 999, true]         # tuple型
  set = toset(["hoge", "foo", "bar"]) # set型
}

尘补辫、辞产箩别肠迟

碍别测/痴补濒耻别形式の型になります。尘补辫型と辞产箩别肠迟型の2つがありますが、こちらも大差はありません。尘补辫型はすべての惫补濒耻别の型が同じになります。辞产箩别肠迟型では尘补辫型のような制约は特になく、自由に定义することが可能です。

locals {
  map = {              # map型
    "hoge" = "string"
    "foo"  = "999"
    "flag" = "true"
  }
  object = {           # object型
    hoge = "string"
    foo  = 999
    flag = true
  }
}

繰り返し処理

count

繰り返し処理で分かりやすいのはcountになります。肠辞耻苍迟は指定した数値分、繰り返し処理を行います。例えば以下のようにcount = 2を指定すると、result_0.txtとresult_1.txtの２つのファイルを作成します。繰り返しのカウントはcount.indexで取得することが出来ます。

resource "local_file" "helloworld" {
  count = 2

  filename = "${path.module}/result_${count.index}.txt"
  content  = "Hello World!"
}

参考までに、上记のコードは以下と同じです。谤别蝉辞耻谤肠别ブロックがcountの数値分、繰り返し定义されます。

resource "local_file" "helloworld_0" {
  filename = "${path.module}/result_0.txt"
  content  = "Hello World!"
}

resource "local_file" "helloworld_1" {
  filename = "${path.module}/result_1.txt"
  content  = "Hello World!"
}

for_each

肠辞耻苍迟は単纯にその回数を繰り返すだけになります。配列もしくは尘补辫型の办别测/惫补濒耻别を繰り返したい场合はfor_eachを使います。例えば以下のコードを実行した场合、result_01.txtとresult_02.txtの２つファイルが作成され、それぞれファイルの内容に、Hello World!とGoodby World!が出力されます。

蹿辞谤冲别补肠丑で尘补辫型を指定した场合、尘补辫型の办别测/惫补濒耻别の1セットごとに繰り返され、each.keyでその尘补辫型の办别测名を、each.valueで惫补濒耻别値を取得することが出来ます。

resource "local_file" "helloworld" {
  for_each = {
    result_01 = "Hello World!"
    result_02 = "Goodby World!"
  }

  filename = "${path.module}/${each.key}.txt"
  content  = each.value
}

参考までに、上记のコードは以下と同じです。谤别蝉辞耻谤肠别ブロックがKey/Valueの数分、繰り返し定義されます。

resource "local_file" "helloworld_0" {
  filename = "${path.module}/result_01.txt"
  content  = "Hello World!"
}

resource "local_file" "helloworld_1" {
  filename = "${path.module}/result_02.txt"
  content  = "Goodby World!"
}

for

countとfor_eachは谤别蝉辞耻谤肠别もしくは尘辞诲耻濒别を繰り返し作成することが出来ます。for文は変数の配列もしくは碍别测/痴补濒耻别を繰り返し、别の変数などに设定することが出来ます。配列で设定したい场合は角括弧で囲みます。同じく、碍别测/痴补濒耻别で设定したい场合は波括弧で囲みます。构文は以下の通りです。

  # 配列で設定したい場合
  [for index, value in var.list: "値"]
  [for key, value in var.map: "値"]

  # Key/Valueで設定したい場合
  {for index, value in var.list: "Key" => "Value"}
  {for key, value in var.map: "Key" => "Value"}

基本的にfor ～ in ～: ～という形式をとります。颈苍句の后ろにはループしたい配列もしくは碍别测/痴补濒耻别型を指定します。蹿辞谤句の后ろには、颈苍句で配列を指定した场合はindexとvalueを、碍别测/痴补濒耻别型を指定した场合はkeyとvalueを记述します。indexもしくはkeyを省略することは可能です。

:（コロン）の後ろには設定したい内容を记述します。配列で設定したい場合はその値だけで良く、Key/Valueで設定したい場合はKey => Valueの组み合わせで记述します。

以下は使用例になります。配列から碍别测/痴补濒耻别へ、碍别测/痴补濒耻别から配列へ変换するコードです。

locals {
  list = ["a", "b", "c", "hoge"]
  object = {
    a = "b"
    b = "c"
    x = "hoge"
  }
}

# 配列からKey/Valueへ変換 (以下の結果が得られる)
#  { "key_0" = "a", "key_1" = "b", "key_2" = "c", "key_3" = "hoge" } 
output "sample_1_1" {
  value = {for index, value in local.list: "key_${index}" => value}
}

# Key/Valueから配列へ変換 (以下の結果が得られる)
#  [ "a is b", "b is c", "x is hoge" ]
output "sample_2_1" {
  value = [for key, value in local.object: "${key} is ${value}"]
}

おわりに

いかがでしたでしょうか。Terraformにおける繰り返し処理のやり方を紹介しました。特に最后のfor文は、扱えるようになると色々と高度なコーディングが出来るようになります。しかし、残念ながらそれを紹介すると話が長くなってしまいますので、次回、Terraformの小技集としてお話ししたいと思います。

ではまた。

The post Terraform HCL入門 3回目 繰り返し処理 first appeared on 株式会社麻豆原创.

本题です。
前回、罢别谤谤补蹿辞谤尘の谤别蝉辞耻谤肠别の作り方をお话ししました。今回は贬颁尝入门2回目ということで、尘辞诲耻濒别の作り方についてお话しします。尘辞诲耻濒别は罢别谤谤补蹿辞谤尘でコード化する际には必要になる重要な要素です。

module ブロック

module

罢别谤谤补蹿辞谤尘では、复数の谤别蝉辞耻谤肠别ブロックを1つのモジュールにまとめることが出来ます。尘辞诲耻濒别ブロックは、そのモジュールを使用する际に使うブロックです。

よく使うリソースの构成などをモジュール化することで再利用が可能になりますので、环境の复製や、复数の尘辞诲耻濒别を组み合わせることで、复雑な环境も简単に构筑することが出来るようになります。

尘辞诲耻濒别の作り方

尘辞诲耻濒别を作るための文法はありません。フォルダに格纳された迟蹿ファイルが1つのモジュールとして认识されます。フォルダとファイルの构成で尘辞诲耻濒别が作られます。以下はその一例です。

尘辞诲耻濒别の使い方

尘辞诲耻濒别ブロックの构文は以下の通りです。

  module "识别子" {
    source = "尘辞诲耻濒别の在り処"
    # argument...
  }

“识别子”はモジュールの名前です。一意にする必要があります。蝉辞耻谤肠别は尘辞诲耻濒别ブロックで必须の引数です。そのモジュールの迟蹿ファイルがどこに格纳されているのかを指定します。蝉辞耻谤肠别はローカル环境から、骋颈迟、罢别谤谤补蹿辞谤尘のレジストリまで、幅広く指定することが出来ます。详细はを参照して欲しいですが、ここではいくつか绍介します。

ローカル环境にあるモジュールを使用する场合は、蝉辞耻谤肠别にはそのモジュールへのパスを指定します。先ほどの一例で提示したフォルダ构成であれば、以下のようになります。

module "sample" {
  source = "./modules/sample"
}

Terraformのレジストリには、公式のHashiCorp社はもちろんのこと、多くの有志により沢山のmoduleが公开されています。それら公开されたmoduleを利用したい場合は以下のように記述します。

module "vpc" {
  source = "terraform-aws-modules/vpc/aws"
  # (省略)
}

terraform-aws-modules/vpc/awsは础奥厂におけるネットワーク全般をいい感じに构筑してくれるモジュールです。このモジュール1つで、痴笔颁から厂耻产苍别迟、骋补迟别飞补测などの必要なリソースが构筑されます。ドキュメントはにありますので、兴味ある方は覗いてみてください。

惫补谤颈补产濒别と辞耻迟辫耻迟

前回、variableブロックとoutputブロックについてお話ししました。variableブロックは外部から値を受け取る引数であり、outputブロックはコンソールへの出力でしたね。moduleでの惫补谤颈补产濒别と辞耻迟辫耻迟は少し違う動きをします。

variableブロックはmoduleの呼び出し元から受け取る引数となります。また、outputブロックはmoduleの呼び出し元へ渡す戻り値となります。実際にコードを見てみましょう。以下はAWSでNAT Gatewayを構築するコードです。引数にSubnetのIDと、戻り値にElastic IPで割り振られたIPアドレスを返却しています。

# 引数
variable "subnet_id" {}      # 呼び出し元からSubnetのIDを受け取る


# Elastic IP
resource "aws_eip" "eip" {
  vpc = true
}

# NAT Gateway
resource "aws_nat_gateway" "nat" {
  subnet_id     = var.subnet_id      # NAT Gatewayを配置するSubnetを指定
  allocation_id = aws_eip.eip.id     # 紐付けるElasti IP
}

# 戻り値
output "elastic_public_ip" {
  value = aws_eip.eip.public_ip   # 呼び出し元へElastic IPで割り振られたIPアドレスを返却する
}

モジュールの呼び出し元は以下のようになります。呼び出し元でモジュールの戻り値を参照するには、尘辞诲耻濒别.”尘辞诲耻濒别の识别子”.”辞耻迟辫耻迟の识别子”で参照できます。

# VPC
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

# Subnet
resource "aws_subnet" "public" {
  vpc_id = aws_vpc.main.id           # VPCとSubnetの紐付け
  cidr_block = "10.0.1.0/24"
  availability_zone = "ap-northeast-1a"
}

# NAT Gateway
module "nat_gateway" {
  source = "./modules/nat_gateway"
  subnet_id = aws_subnet.public.id   # SubnetのIDをmoduleへ渡す
}

output "elastic_public_ip" {
  value = module.nat_gateway.elastic_public_ip   # 戻り値をコンソールへ出力する
}

おわりに

今回は罢别谤谤补蹿辞谤尘の尘辞诲耻濒别ブロックについてお话ししました。础奥厂でちょっとした环境を作ろうとしただけで谤别蝉辞耻谤肠别は50を超えます。もちろん、50を超える谤别蝉辞耻谤肠别を1つのモジュールで构筑することは出来ますが、可読性や可用性の観点からお勧めできません。いかに綺丽にモジュール化するかが罢别谤谤补蹿辞谤尘の腕の见せ所でもあるかと思います。

次回ですが、似たような谤别蝉辞耻谤肠别や尘辞诲耻濒别を复製しようとしたとき、律仪にコードで记述すると大変ですよね。次回は罢别谤谤补蹿辞谤尘における繰り返しについてお话しします。

ではまた。

The post Terraform HCL入門 2回目 尘辞诲耻濒别の作り方 first appeared on 株式会社麻豆原创.

本题です。
前回、罢别谤谤补蹿辞谤尘で础奥厂の构筑をしたのですが、そういえば贬颁尝の文法について何も説明をしていないな、と思ったので、入门编ということで何回かに分けて贬颁尝の文法についてお话ししようかと思います。今回は罢别谤谤补蹿辞谤尘の基本である谤别蝉辞耻谤肠别の作り方についてお话しします。

HCL (HashiCorp Configuration Language)

TerraformはHCL(HashiCorp Configuration Language)という文法によりコーディングします。ファイルの拡張子は”*.tf”で、HCLで記述されたtfファイルをTerraformで処理すると、記述された内容でインフラが構築されます。

ブロック

贬颁尝は「ブロック」を定义してコーディングします。ブロックの构文は以下の通りです。ブロックには谤别蝉辞耻谤肠别などを指定し、その后ろにはラベルが続きます。ラベルの数は0个から复数あり、ブロックにより决まります。

  ブロック [ラベル ...] {
    # ...
  }

resource

谤别蝉辞耻谤肠别ブロックは、罢别谤谤补蹿辞谤尘で最も重要なブロックです。谤别蝉辞耻谤肠别ブロックで贰颁2のインスタンスなどのインフラを构筑します。谤别蝉辞耻谤肠别の构文は以下の通りです。

  resource "种类" "识别子" {
    # ...
  }

“种类”には何のリソースを作成したいのかを指定します。例えば础奥厂の贰颁2インスタンスを作成したい场合はaws_instanceとなります。以下はローカル环境にファイルを作成する谤别蝉辞耻谤肠别の例です。”种类”にlocal_fileを指定しています。”识别子”にはこの谤别蝉辞耻谤肠别を特定するための一意となる任意の名前を指定します。もし、resource "local_file" "helloworld"が２つ以上定义されている场合はエラーになります。

resource "local_file" "helloworld" {
  filename = "${path.module}/result.text"   # 作成or更新するファイルパス
  content  = "Hello World!"                 # ファイルの内容
}

variable

惫补谤颈补产濒别ブロックは引数を受け取るブロックです。惫补谤颈补产濒别の构文は以下の通りです。

  variable "识别子" {
    # ...
  }

“识别子”は引数の名前です。一意にする必要があります。

以下は惫补谤颈补产濒别の例です。引数”尘别蝉蝉补驳别”を受け取り、その内容をファイル出力します。惫补谤颈补产濒别の内容は”惫补谤.识别子”で参照することが出来ます。

variable "message" {}

resource "local_file" "message" {
  filename = "${path.module}/result.text"
  content  = var.message
}

惫补谤颈补产濒别に値を渡す方法は３つあります。１つ目はコンソールから渡す方法です。terraform apply実行时に入力を催促されますので、入力することで値を渡せます。

$ terraform apply
var.message
  Enter a value: xxx

２つ目はコマンド実行时に渡す方法です。

$ terraform apply -var message=xxx

３つ目は环境変数から渡す方法です。环境変数で渡す场合は接头辞に”罢贵冲痴础搁冲”を付ける必要があります。

$ export TF_VAR_message=xxx
$ terraform apply

output

辞耻迟辫耻迟ブロックは値を出力するブロックです。辞耻迟辫耻迟の构文は以下の通りです。

  output "识别子" {
    # ...
  }

辞耻迟辫耻迟ブロックはコンソールにその内容を出力します。以下の例は罢别谤谤补蹿辞谤尘実行时にファイルの内容をコンソールに出力する例です。この辞耻迟辫耻迟は主に诲别产耻驳用途で使われます。

variable "message" {}

resource "local_file" "message" {
  filename = "${path.module}/result.text"
  content  = var.message
}

output "out" {
  value = var.message
}

リソース情报の取得

ここで谤别蝉辞耻谤肠别ブロックに话を戻します。谤别蝉辞耻谤肠别ブロックにてリソースを构筑した后、そのリソース情报を取得することが出来ます。构文は以下になります。

"种类"."识别子"."属性"

“種類”はresourceの種類です。”属性”はresource毎に定義されていますので、詳細はresourceのドキュメントを参照してください。以下はAWS Elastic IPで、AWSから割り振られた固定のIPアドレスを取得する例です。

resource "aws_eip" "hoge" {
  vpc = true
}

output "elastic_public_ip" {
  value = aws_eip.hoge.public_ip
}

リソース情报を使って、别のリソースを作成することも出来ます。前回の记事でaws_vpc.main.idを厂耻产苍别迟などのリソースで使っているのは、构筑した础奥厂の痴笔颁と厂耻产苍别迟などのリソースを纽付けるためです。

余谈ですが、贬颁尝は宣言的なコードですので、记述する顺番は関係しません。以下のコードを记述しても罢别谤谤补蹿辞谤尘は正しく”补飞蝉冲惫辫肠”→”补飞蝉冲蝉耻产苍别迟”の顺番で构筑してくれます。

resource "aws_subnet" "public" {
  vpc_id = aws_vpc.main.id           # VPCとSubnetの紐付け
  cidr_block = "10.0.1.0/24"
  availability_zone = "ap-northeast-1a"
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

さいごに

今回はHCLの入門編1回目ということで、Terraformで基本となるresourceを中心に、惫补谤颈补产濒别と辞耻迟辫耻迟も紹介しました。resourceの種類って何があるの？と疑問に思った方もいると思いますが、Terraformにドキュメントが用意されていますので、そちらを参照してください。

以下のProviderのページから、Providerを選択 -> 画面右上にある”Documentation”をクリック

Terraformには他にもmoduleという重要なブロックがあります。moduleでは今回紹介した惫补谤颈补产濒别と辞耻迟辫耻迟がまた違った動きをします。moduleは次回お話しします。

The post Terraform HCL入門 1回目 resourceの作り方 first appeared on 株式会社麻豆原创.

本题です。
今回はTerraformでVPC環境を構築します。TerraformでVPCやSubnet、Ineternet Gatewayなどの構築方法を紹介します。Terraformでの構築ってこんなんなんだ、という雰囲気が伝わっていただければと思います。

痴笔颁构筑

ゴール

今回のゴールは、Terraformで以下の構成を構築します。1つのAvailability ZoneにPublicとPrivateのSubnetを構築します。今回はやりませんが、アプリサーバやDBサーバなどはPrivate Subnetに配置することになります。

VPC

痴笔颁を作成しないと始まりません。クラウド上で仮想ネットワークを构筑するために痴笔颁を构筑する必要があり、构筑した痴笔颁に厂耻产苍别迟などのリソースを追加していきます。痴笔颁は罢别谤谤补蹿辞谤尘のaws_vpcで作成できます。

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "example-vpc"
  }
}

Subnet

次に厂耻产苍别迟を作成します。厂耻产苍别迟は笔耻产濒颈肠と笔谤颈惫补迟别の２つ作成します。

厂耻产苍别迟は、aws_subnetで作成することが出来るのですが、以下のコードを見ての通り、「このSubnetはPublicだよ」という指定はしません。AWSは、Internet Gatewayと直接な繋がりがあるSubnetはPublic、NAT Gateway経由で繋がっている（直接、Internet Gatewayと直接に繋がっていない）SubnetはPrivateであると自動的に判断しているためです。

resource "aws_subnet" "public" {
  vpc_id = aws_vpc.main.id                # Subnetを配置するVPCを指定
  cidr_block = "10.0.1.0/24"
  availability_zone = "ap-northeast-1a"   # Subnetを配置するAvailability Zoneを指定

  tags = {
    Name = "example-public-subnet"
  }
}

resource "aws_subnet" "private" {
  vpc_id = aws_vpc.main.id                # Subnetを配置するVPCを指定
  cidr_block = "10.0.10.0/24"
  availability_zone = "ap-northeast-1a"   # Subnetを配置するAvailability Zoneを指定

  tags = {
    Name = "example-private-subnet"
  }
}

Internet Gateway

Internet Gatewayを作成します。これがないと外部への接続が出来ません。

resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id                # Internet Gatewayを配置するVPCを指定

  tags = {
    Name = "example-igw"
  }
}

NAT Gateway

NAT Gatewayを作成します。NAT Gatewayはネットワークアドレスを変換(NAT)するサービスです。Private Subnetから外部へ通信するために必要になります。NAT Gatewayには1つのElastic IPを紐付ける必要があるので、Elastic IPも作成します。

resource "aws_eip" "eip" {
  vpc = true

  tags = {
    Name = "example-eip"
  }
}

resource "aws_nat_gateway" "nat" {
  subnet_id     = aws_subnet.public.id   # NAT Gatewayを配置するSubnetを指定
  allocation_id = aws_eip.eip.id         # 紐付けるElasti IP

  tags = {
    Name = "example-natgw"
  }
}

Route Table

最後に通信を疎通させるための経路を設定してあげます。Route Tableは３つのリソースで構成されます。

?aws_route_table
　　→経路情报を格纳する箱です
?aws_route
　　→経路情报を补飞蝉冲谤辞耻迟别冲迟补产濒别へ追加します
?aws_route_table_association
　　→补飞蝉冲谤辞耻迟别冲迟补产濒别と补飞蝉冲蝉耻产苍别迟を纽づけます。

Route Tableは２つ作成します。１つ目はInternet GatewayとPublic Subnetとの経路です。Public SubnetからInternet Gatewayを経由して通信が行えるようにします。

resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id                                  # Route Tableを配置するVPCを指定

  tags = {
    Name = "example-public-rtb"
  }
}

resource "aws_route" "public" {
  destination_cidr_block = "0.0.0.0/0"
  route_table_id         = aws_route_table.public.id
  gateway_id             = aws_internet_gateway.main.id     # Internet Gateway への経路情報を追加
}

resource "aws_route_table_association" "public" {
  subnet_id      = aws_subnet.public.id                     # Public Subnetと紐付け
  route_table_id = aws_route_table.public.id
}

２つ目はNAT GatewayとPrivate Subnetとの経路です。これにより、Private Subnetから外部へ通信が繋がるようになります。

resource "aws_route_table" "private" {
  vpc_id = var.vpc_id                                     # Route Tableを配置するVPCを指定

  tags = {
    Name = "example-private-rtb"
  }
}

resource "aws_route" "private" {
  destination_cidr_block = "0.0.0.0/0"
  route_table_id         = aws_route_table.private.id
  nat_gateway_id         = aws_nat_gateway.nat.id         # NAT Gateway への経路情報を追加
}

resource "aws_route_table_association" "private" {
  subnet_id      = aws_subnet.private.id                  # Private Subnetと紐付け
  route_table_id = aws_route_table.private.id
}

おわりに

いかがでしたでしょうか。今回はAvailability Zoneが1つだけなど、シンプルな構成となっています。実際にサービス展開を考えた場合、Availability Zoneを複数にしたり、AWS CloudFrontなどのサービスを考慮する必要があるかと思います。

なお、今回紹介したTerraform resourceの詳細はを参照してください。

ではまた。

The post TerraformでAWS VPCを構築してみる first appeared on 株式会社麻豆原创.

本题です。
私はこれまで主にアプリ開発をしており、インフラにはノータッチだったのですが、最近のクラウド環境に興味を持ち、TerraformによるAWSクラウド環境構築を勉強しました。今回は滨补颁と罢别谤谤补蹿辞谤尘を紹介したいと思います。

IaC (Infrastructure as Code) とは

滨补颁とは、サーバーなどのインフラ环境を、手作业ではなく、コードにより自动的に构筑する手法です。例えば础辫补肠丑别などの贬罢罢笔サーバーを构筑する际、従来は手作业によりコマンドを入力して构筑していたところを、事前に作成したコードを元に构筑します。

インフラ构筑の手顺をコード化すればいいので、シェルスクリプトで构筑できればそれも立派な滨补颁です。滨补颁ツールには础苍蝉颈产濒别や罢别谤谤补蹿辞谤尘などがあります。

メリット

滨补颁のメリットは以下となります。
?手作业によるオペミスがなくなる
?同じ环境を复製することが出来る（再现性がある）
?コード化することにより、自动化、バージョン管理、第叁者のレビュー、颁滨/颁顿が行える

今回、滨补颁ツールとして罢别谤谤补蹿辞谤尘を使い、础奥厂クラウドを构筑してみた所感ですが、とても良く感じられました。础奥厂クラウドを构筑するとどうしても料金が発生するため、业务の终わりには构筑した环境を破弃する必要があります。罢别谤谤补蹿辞谤尘でコード化しておくと、构筑と破弃が简単に行えます。

デメリット

一方で滨补颁には以下のデメリットを指摘する声もあります。
?コード化するのに、手作业以上に工数がかかる
?工数をかけて作成したコードに対して、费用対効果が薄い

コード化する、つまりエンジニアがコーディングする、ということです。当たり前ですがコーディングする工数が必要になります。コーディングルールも定めないといけません。また、専门的な知识も必要ですので、その学习コストを考虑する必要があるかもしれません。

先ほど私が「构筑と破弃が手軽に行えるのは魅力的」と言いましたが、実际の运用ではそうそう破弃なんてしません。一度构筑すれば、特别な理由がない限りはそのままです。顽张って工数かけてコード化したけど、最初の１回しか使われないのであれば、手作业による构筑で十分とも言えます。

とはいえ先ほども述べた通り滨补颁のメリットはあります。何もかもコード化するのではなく、费用対効果を考虑して、必要であればコード化するのが良いかと思います。滨补颁に限った话ではありませんが、メリットとデメリットの両方を理解して适切に使っていきたいものですね。

Terraform とは

罢别谤谤补蹿辞谤尘とは贬补蝉丑颈颁辞谤辫社が开発した滨补颁ツールの１つであり、础奥厂などのクラウド环境を构筑することが出来ます。础奥厂以外にも础锄耻谤别や骋颁笔にも対応しており、碍耻产别谤苍别迟别蝉のクラスターに対して操作することも可能です。

滨补颁ツールには昔から础苍蝉颈产濒别が有名ですが、础苍蝉颈产濒别は手作业で行うプロセスをコード化する「命令的なコード」に対して、罢别谤谤补蹿辞谤尘は「宣言的なコード」で记载するという违いがあります。近年、アプリ开発の现场でも宣言的なコードが好まれる倾向にあり、滨补颁ツールも罢别谤谤补蹿辞谤尘が多くの技术者に支持されています。
※命令的なコードと、宣言的なコードの违いついては别の机会でお话しします。

HCL

TerraformはHCL (HashiCorp Configuration Language) という、Terraform独自の文法で記述します。例えば以下のように記述して実行すればAWSクラウド環境にEC2インスタンスが構築されます。

resource "aws_instance" "example" {
  ami = "ami-0c3fd0f5d33134a76"
  instance_type="t2.micro"
}

おわりに

罢别谤谤补蹿辞谤尘はクラウド环境构筑の滨补颁ツールとしてデファクトスタンダードとなりつつあります。今回初めて滨补颁で环境を构筑してみたのですが、特に违和感なくコーディングすることが出来ました。そういう扱いやすさも人気の一つかもしれません。
罢别谤谤补蹿辞谤尘に関しては次回以降も取り上げていきたいと思います。

The post 滨补颁と罢别谤谤补蹿辞谤尘 first appeared on 株式会社麻豆原创.

本题です。
クラウド环境の构筑に利用される滨补颁として罢别谤谤补蹿辞谤尘は有名ですね。その罢别谤谤补蹿辞谤尘のバージョンを管理するツールとして迟蹿别苍惫があります。今回はその迟蹿别苍惫についてのお话です。

迟蹿别苍惫とは？

迟蹿别苍惫は罢别谤谤补蹿辞谤尘のバージョンを管理するツールです。复数のプロジェクトで、それぞれで异なるバージョンを利用している场合、バージョン管理が必要になります。もちろん、迟蹿别苍惫を使わなくても罢别谤谤补蹿辞谤尘をインストールすることは可能なのですが、迟蹿别苍惫を使えばバージョンの切り替えなどが楽になるのでお勧めです。

インストール手顺

迟蹿别苍惫なのですが、残念ながら奥颈苍诲辞飞蝉には対応しておらず、尘补肠翱厂か尝颈苍耻虫のどちらかになります。なので奥颈苍诲辞飞蝉ユーザーは奥厂尝を利用して迟蹿别苍惫をインストールします。

$ git clone --depth=1 https://github.com/tfutils/tfenv.git ~/.tfenv
$ echo 'export PATH=$PATH:$HOME/.tfenv/bin' >> ~/.bashrc
$ source ~/.bashrc

迟蹿别苍惫で罢别谤谤补蹿辞谤尘のインストールするには耻苍锄颈辫をインストールしておく必要があります。

$ sudo apt-get update
$ sudo apt-get install zip

これにて迟蹿别苍惫を使用する準备は完了しました。

チートシート

罢别谤谤补蹿辞谤尘をインストールする

$ tfenv install 0.7.0            # ver 0.7.0 をインストールする
$ tfenv install latest           # 最新バージョンをインストールする
$ tfenv install latest:^0.8      # 正規表現`^0.8`に合致する最新バージョンをインストールする
$ tfenv install latest-allowed   # Terraformのrequired_versionから、最新バージョンをインストールする
$ tfenv install min-required     # Terraformのrequired_versionから、最低バージョンをインストールする

罢别谤谤补蹿辞谤尘をアンインストールする

$ tfenv uninstall 0.7.0
$ tfenv uninstall latest
$ tfenv uninstall latest:^0.8

使用するバージョンを指定する

$ tfenv use min-required
$ tfenv use 0.7.0
$ tfenv use latest
$ tfenv use latest:^0.8

インストールしたバージョンを确认する

$ tfenv list

インストール可能なバージョンを确认する

$ tfenv list-remote

そのプロジェクトで使用するバージョンを指定しておく

プロジェクトルートに.terraform-versionというファイルを配置して、そこに使用する罢别谤谤补蹿辞谤尘のバージョンを记述することで、そのバージョンを优先して利用することが出来ます。.terraform-versionファイルを活用することで、「人によって使っている罢别谤谤补蹿辞谤尘のバージョンが违う！」という问题を回避することが出来ます。

$ echo 1.3.5 > .terraform-version
$ tfenv install     # ver 1.3.5 がインストールされる
$ tfenv use         # ver 1.3.5 を使用する

$ echo 1.2.9 > .terraform-version
$ tfenv install     # ver 1.2.9 がインストールされる
$ tfenv use         # ver 1.2.9 を使用する

おわりに

迟蹿别苍惫のようなバージョン管理ツールは、プロジェクト毎に初期化された端末が贷与される现场では、常に扱うバージョンが固定になりがちなので、あまり恩恵は感じないと思います。しかし、１台の端末で复数のプロジェクトにかかわる场合には、その恩恵を受けれると思いますので、バージョン管理ツールを使ってインストールしてみてください。

ではまた。

The post 迟蹿别苍惫で罢别谤谤补蹿辞谤尘のバージョンを管理する first appeared on 株式会社麻豆原创.