CloudFormationには Resource importing機能 があります。
これを利用して、CDKで既存のリソースを管理できないかなと思いました。
実験してみたらできたので、その方法を共有します。

なお、これは fromArn 系のメソッドで既存リソースを参照する方法ではなく、CDKネイティブのリソースとして既存リソースを扱うことができる方法です。
参照: https://github.com/aws/aws-cdk-rfcs/issues/52

今回対象にするケース

Toy example として、既存のSQSキューをCDK管理下にインポートする方法を紹介します。

前提として import_test_queue という名前のSQSキューがすでに作成されているとします（下図。）

手順

1. CDKでインポートしたいリソースを定義するコードを書く

CFnのResource importingを使うには、CFnテンプレートを用意する必要があります。
このテンプレートを生成するためのCDK Stackを定義します。
このコードは、これらの手順が完了した後同リソースを管理するためにそのまま利用することができます。

import-test-stack.ts

import * as sqs from '@aws-cdk/aws-sqs';
import * as cdk from '@aws-cdk/core';

export class ImportTestStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    new sqs.Queue(this, 'queue', {
      queueName: 'import_test_queue',
    });
  }
}

cdk.ts

#!/usr/bin/env node
import * as cdk from '@aws-cdk/core';
import { ImportTestStack } from '../lib/import-test-stack';

const app = new cdk.App();

new ImportTestStack(app, 'import-test-stack', {
    stackName: 'import-test-stack',
});

注意点として、 queueName は既存リソースと合わせてください。（今回は import_test_queue）
また、Stack名についても今後作成するStackの名前と同一にする必要があります。（今回は import-test-stack）

2. テンプレートを生成する

上記のCDKコードから cdk synth でCFnテンプレートを作成します。

npm run build
npm run cdk synth

cdk.out ディレクトリには下記の import-test-stack.template.json が生成されるはずです。

import-test-stack.template.json

{
  "Resources": {
    "queue276F7297": {
      "Type": "AWS::SQS::Queue",
      "Properties": {
        "QueueName": "import_test_queue"
      },
      "Metadata": {
        "aws:cdk:path": "import-test-stack/queue/Resource"
      }
    },
    "CDKMetadata": {
      "Type": "AWS::CDK::Metadata",
      "Properties": {
        "Modules": "aws-cdk=1.64.1,@aws-cdk/assets=1.64.1,@aws-cdk/aws-applicationautoscaling=1.64.1,@aws-cdk/aws-autoscaling=1.64.1,@aws-cdk/aws-autoscaling-common=1.64.1,@aws-cdk/aws-cloudwatch=1.64.1,@aws-cdk/aws-codeguruprofiler=1.64.1,@aws-cdk/aws-ec2=1.64.1,@aws-cdk/aws-eks=1.64.1,@aws-cdk/aws-elasticloadbalancingv2=1.64.1,@aws-cdk/aws-events=1.64.1,@aws-cdk/aws-iam=1.64.1,@aws-cdk/aws-kms=1.64.1,@aws-cdk/aws-lambda=1.64.1,@aws-cdk/aws-logs=1.64.1,@aws-cdk/aws-s3=1.64.1,@aws-cdk/aws-s3-assets=1.64.1,@aws-cdk/aws-sqs=1.64.1,@aws-cdk/aws-ssm=1.64.1,@aws-cdk/cloud-assembly-schema=1.64.1,@aws-cdk/core=1.64.1,@aws-cdk/custom-resources=1.64.1,@aws-cdk/cx-api=1.64.1,@aws-cdk/region-info=1.64.1,jsii-runtime=node.js/v14.13.0"
      }
    }
  }
}

3. 生成されたテンプレートをResource importing用に加工する

CFnのResource importingを利用するには、CFnテンプレートがいくつかの制約を満たしている必要があります。
このうち、上記のテンプレートが問題になるのは下記です:

• DeletionPolicy が指定されている必要がある
• AWS::CDK::Metadata リソースを含んではならない

この条件を満たせるように、先のテンプレートを手で編集します。
編集後のテンプレートは下記です。

import-test-stack.template.json

{
  "Resources": {
    "queue276F7297": {
      "Type": "AWS::SQS::Queue",
      "DeletionPolicy": "Retain",
      "Properties": {
        "QueueName": "import_test_queue"
      },
      "Metadata": {
        "aws:cdk:path": "import-test-stack/queue/Resource"
      }
    }
  }
}

4. CFnのResource Importing機能でStackを作成する

ウェブコンソールから、下記の手順でStackを作成します。

スタックの作成 → 既存のリソースを使用 をクリックし、Resouce importingのウィザードを開始します。

先程作成したテンプレートを指定してください。

インポートしたいキューの QueueUrl をSQSコンソールからコピーします。

スタックの名前は、 cdk.ts で指定したものと同一にします。

これまで正しく実行できていれば、インポートできます。
リソースをインポート ボタンをクリックしてください。

インポート完了です！

5. cdkから同じスタックをデプロイする

これで、CDKからStackを操作できるようになりました。
試しに cdk diff してみてください

diff

$ npm run cdk diff import-test-stack

Stack import-test-stack
Resources
[~] AWS::SQS::Queue queue queue276F7297 
 └─ [-] DeletionPolicy
     └─ Retain

先程手で追加したDeletionPolicyを削除するようなdiffが表示されています。
想定通りですね。

cdk deploy してみましょう。

$ npm run cdk deploy import-test-stack

import-test-stack: deploying...
import-test-stack: creating CloudFormation changeset...
[██████████████████████████████████████████████████████████] (3/2)

 ✅  import-test-stack

こちらもうまくいきました。

コンソールからStackを見ると、CDK Metadataリソースが合わせて作成されていることが分かります。

以上で、手順は完了です。

CDKのコードを変更することで、CDKネイティブのStackと全く同様にリソースを変更できます。
これは fromArn などによる参照を取得する機能では実現できなかったものです。

$ npm run build && npm run cdk diff import-test-stack

Stack import-test-stack
Resources
[~] AWS::SQS::Queue queue queue276F7297 
 └─ [+] MessageRetentionPeriod
     └─ 1200

まとめ

• CDKでも間接的にCFnのResource importingを使うことができます
• 多くのサービスはResource importingが対応されているので、使うと良いでしょう
• fromArn などを使うよりは、こちらのほうがCDKのメリットを享受しやすいです

キーワードで勉強しよう！

クラウドコンピューティング

ネットワーク・サーバ・データベースなどの機能をクラウド上で提供して最も早くインプラを構築できる記述。
インプラを構築するのに発生した莫大な費用コストや人的資源を削減できるし、最初の使用以降にもベンダーが管理とアップデートしてくれるため、使用者のインプラ運用難易度を下げてくれる。

クラウドコンピューティングの頂点

・すでに構築されている環境を借りるため、コスト低いかつ導入速度が速い。
・最初の構築コストや管理費が発生しない。（使った分だけ料金がかかる）
・インターネットに接続されていれば、パソコン、タブレット、スマートフォンなどデバイスを問わない。
・システムを提供するプロバイダーが一元管理しているので、セキュリティやシステムのアップデートが自動で行われる（保安対策を気にする必要がない）

クラウドコンピューティングの種類

・OS、ハードウェア、ネットワークのみクラウドから提供するIaaS（Infrastructure as a Service）→　コンピュータ本来の機能を提供
・IaaSの機能とミドルウェアをクラウドから提供するPaaS（Platform as a Service）→　WindowsなどのOSまで提供
・PaaSの機能とアプリケーションもクラウドから提供するSaaS（Software as a Service）→　起動可能なプログラム単位まで提供

AWS(Amazon Web Service)

AWSはアマゾンから提供するクラウドファンディング

参考

参考１
参考２

概要

CDKを使ってAWS環境を作成するときの方法についてまとめていこうと思います。
前回の続きです。
定義にはS3,DynamoDB,RDSの部分もありますがそのあたりは次回以降に・・・

準備

• 前回の転記部分もあります。詳細は前回を参照
• AWS SummitのCDKハンズオンを見て準備をしましょう。
• こちらでも簡単に準備手順を
  • AWS CLIのインストール
  • AWS Configureの設定
    • アカウントはCDKで作成するリソースにアクセスできる権限を付与しましょう。(お試しでやる場合はAdministrator権限の方がいいかもしれません)
  • node.jsのインストール
  • npm install -g aws-cdk のコマンドでcdkをインストール

プロジェクトの準備

• TypeScriptでの例となります。
• 空のディレクトリを用意する。
• ディレクトリに移動して以下のコマンドを実行する
  • cdk init sample-app --language typescript
• 初期ディレクトリなどが作成されるのを待ちます。

ライブラリのインストール

• 必要に応じて npm コマンドでライブラリをインストールします。以下のようなコマンドです。
  • npm install @aws-cdk/aws-ecs
  • npm install @aws-cdk/aws-batch
  • npm install @aws-cdk/aws-ec2
  • npm install @aws-cdk/aws-iam
  • npm install @aws-cdk/aws-ecr
• 注意点
  • ライブラリのバージョンが一致していないとコンパイルエラーやdeploy時にエラーになるので package.json のバージョンを合わせて、 package-lock.json と node_modules 配下を削除して npm install を実施しましょう。

コンパイルの準備

• ライブラリインストール後にプロジェクトを作成したディレクトリに移動して以下のコマンドを実行します。windowsの場合はライブラリのインストール時には停止する必要があるので注意を
  • npm run watch

各ソースの説明

• ./lib/cdk-stack.ts
  • 各定義を作成する場所です。基本的にこのファイルを修正します

CDKの定義

• VPCなどを指定する部分はIDを指定します。

• ソース全体

長いので折りたたんでます

import * as cdk from '@aws-cdk/core';
import * as batch from '@aws-cdk/aws-batch';
import * as dynamodb from '@aws-cdk/aws-dynamodb';
import * as rds from '@aws-cdk/aws-rds';
import * as s3 from '@aws-cdk/aws-s3';
import * as ec2 from '@aws-cdk/aws-ec2';
import * as iam from '@aws-cdk/aws-iam';
import * as ecs from '@aws-cdk/aws-ecs';
import * as ssm from '@aws-cdk/aws-ssm';
import * as ecr from '@aws-cdk/aws-ecr';
import { ContainerImage, EcrImage } from '@aws-cdk/aws-ecs';
import { Repository } from '@aws-cdk/aws-ecr';
import { ServerlessCluster, SubnetGroup } from '@aws-cdk/aws-rds';
import { Effect } from '@aws-cdk/aws-iam';


export class CdkStack extends cdk.Stack {

  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {

    super(scope, id, props);


    const vpc: ec2.IVpc = ec2.Vpc.fromLookup(this, 'VPC', {
      vpcId: 'vpc-0890be0a4389aa3b3',
    });
    const selectSubnets: ec2.SelectedSubnets = vpc.selectSubnets({
      subnets: [
        ec2.Subnet.fromSubnetAttributes(this, 'Subnet', {
          subnetId: 'subnet-0f3d599ff3a439e8b',
          availabilityZone: 'ap-northeast-1a',
          routeTableId: 'rtb-0b3f9acea163735d2',
        }),
      ]
    });


    // 既存のセキュリティーグループを取得
    const securityGroup: ec2.ISecurityGroup = ec2.SecurityGroup.fromSecurityGroupId(
      this, 'SecurityGroup', 'sg-011b45aab947a7b11',
    );


    // バッチのロール
    const batchRole: iam.IRole = new iam.Role(this, 'BatchRole', {
      roleName: 'TestBatchRole',
      assumedBy: new iam.CompositePrincipal(
        new iam.ServicePrincipal('batch.amazonaws.com'),
      ),
      managedPolicies: [
        iam.ManagedPolicy.fromManagedPolicyArn(
          this,
          'AWSBatchServiceRole',
          'arn:aws:iam::aws:policy/service-role/AWSBatchServiceRole',
        ),
      ],
    });

    // インスタンスのロール S3とDynamoDBへのアクセスを追加
    const instanceRole: iam.IRole = new iam.Role(this, 'InstanceRole', {
      roleName: 'TestInstanceRole',
      assumedBy: new iam.CompositePrincipal(
        new iam.ServicePrincipal('ec2.amazonaws.com'),
      ),

      managedPolicies: [
        iam.ManagedPolicy.fromManagedPolicyArn(
          this,
          'AmazonEC2ContainerServiceforEC2Role',
          'arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role',
        ),
        iam.ManagedPolicy.fromManagedPolicyArn(this,'AwsS3FullAccess','arn:aws:iam::aws:policy/AmazonS3FullAccess'),
        iam.ManagedPolicy.fromManagedPolicyArn(this,'AwsDynamoFullAccess','arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess')
      ],
    });

    // Job用ロールを作成
    const jobRole: iam.IRole = new iam.Role(this, 'JobRole', {
      roleName: 'TestJobRole',
      assumedBy: new iam.CompositePrincipal(
        new iam.ServicePrincipal('ecs-tasks.amazonaws.com'),
      ),
      managedPolicies: [
        iam.ManagedPolicy.fromManagedPolicyArn(
          this,
          'AmazonECSTaskExecutionRolePolicy',
          'arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy',
        ),
      ],
    });

    // インスタンスプロフィールを作成
    const instanceProfile: iam.CfnInstanceProfile = new iam.CfnInstanceProfile(this, 'InstanceProfile', {
      instanceProfileName: 'Testprofile',
      roles: [instanceRole.roleName],

    });

    // コンピューティング環境を作成
    const computeEnvironment: batch.ComputeEnvironment = new batch.ComputeEnvironment(this, 'BatchCompute', {
      computeEnvironmentName: 'TestComputeEnvironment',
      computeResources: {
        type: batch.ComputeResourceType.ON_DEMAND,
        instanceRole: instanceProfile.attrArn,
        vpc: vpc,
        vpcSubnets: selectSubnets,
        securityGroups: [securityGroup],
      },
      serviceRole:batchRole
    });
    const repository = Repository.fromRepositoryName(this,'pandastestRepo','pandastest2')
    const ecscontainerImage =  ecs.ContainerImage.fromEcrRepository( repository,'latest')

    // jobのQueを作成
    new batch.JobQueue(this, 'JobQueue', {
      jobQueueName: 'jobQueque',
      computeEnvironments: [{
          computeEnvironment: computeEnvironment,
          order: 1,
      }],
    });

    const jobDefinec = new batch.JobDefinition(this, 'JobDefinition', {
      jobDefinitionName: 'pandasTest',
      container: {
        command: ['1','3','A'],  // コンテナ内で実行されるコマンド
        environment: {'RDS_PASS': 'password','TEST':'ABC'},
        image: ecscontainerImage,
        jobRole: jobRole,
        vcpus: 1,
        memoryLimitMiB: 32,
      },
    });


    //  RDS周り
    const selectRdsSubnets: ec2.SelectedSubnets = vpc.selectSubnets({
      subnets: [
        ec2.Subnet.fromSubnetAttributes(this, 'Subnet1', {
          subnetId: 'subnet-0f3d599ff3a439e8b',
          availabilityZone: 'ap-northeast-1a',
          routeTableId: 'rtb-0b3f9acea163735d2',
        }),
        ec2.Subnet.fromSubnetAttributes(this, 'Subnet2', {
          subnetId: 'subnet-08a1d1ea639bb8876',
          availabilityZone: 'ap-northeast-1a',
          routeTableId: 'rtb-0b3f9acea163735d2',
        }),
      ]
    });

    const subnetGroup=new rds.SubnetGroup(this,'subnetgroup',{
      vpc:vpc,
      description:'for rds subnetGroup',
      subnetGroupName:'sdfsubnetgroup',
      vpcSubnets:selectRdsSubnets
    })




    const dbname='testdb';
    const masterUsername='root';
    const masterPassword='password';

    const rdsCluster = new rds.CfnDBCluster(this, 'DBCluster', { 
      engine: 'aurora-mysql',
      dbClusterIdentifier: `main-cluster`,
      engineMode: 'serverless',
      engineVersion: '5.7.mysql_aurora.2.07.1',
      enableHttpEndpoint: false,
      databaseName: dbname,
      masterUsername: masterUsername,
      masterUserPassword: masterPassword,
      backupRetentionPeriod:  1 ,
      dbSubnetGroupName:subnetGroup.subnetGroupName,
      scalingConfiguration: {
        autoPause: true,
        maxCapacity:  2 ,
        minCapacity: 1,
        secondsUntilAutoPause:  600 ,
      },
      deletionProtection:  false ,
    });

    // S3
    const dataBucket = new s3.Bucket(this, 'pf-bucket-data', {
      bucketName: `bucket-data-${this.region}-${this.account}`,
      blockPublicAccess:s3.BlockPublicAccess.BLOCK_ALL
  });
  // S3 BucketPolicy
  const dataBucketPolicy = new s3.BucketPolicy(this, 'pf-bucket-data-policy', {
      bucket : dataBucket,
  });

const s3dataStatement = new iam.PolicyStatement({
  effect: Effect.ALLOW,
      actions:['s3:ListBucket','s3:PutObject','s3:ListBucket'],
      resources:[
        "arn:aws:s3:::" + dataBucket.bucketName,
        "arn:aws:s3:::" + dataBucket.bucketName + "/*"
      ],
      principals:[new iam.AccountPrincipal(this.account)]
  })
    const s3Statement = new iam.PolicyStatement({
      effect: Effect.ALLOW,
          actions:['s3:ListBucket','s3:PutObject','s3:ListBucket'],
          resources:[
            "arn:aws:s3:::" + dataBucket.bucketName,
            "arn:aws:s3:::" + dataBucket.bucketName + "/*"
          ]
      })

      const s3Statementssm = new iam.PolicyStatement({
        effect: Effect.ALLOW,
            actions:['ssm:DescribeParameters','ssm:GetParameter'],
            resources:['*']
        })


  dataBucketPolicy.document.addStatements(s3dataStatement)



  const sdfDynamoDB=new dynamodb.Table(this,'sdfCountTable',{
    partitionKey: {
      name: "sequence_key",
      type: dynamodb.AttributeType.STRING,
    },
    tableName:'sequence_table_cdk',
    billingMode:dynamodb.BillingMode.PROVISIONED,
    removalPolicy: cdk.RemovalPolicy.DESTROY,
    readCapacity:2,
    writeCapacity:2,


  })


    const dynamoDbStatement = new iam.PolicyStatement({
      effect: Effect.ALLOW,
      actions:[
        "dynamodb:BatchGetItem",
        "dynamodb:BatchWriteItem",
        "dynamodb:PutItem",
        "dynamodb:ListTables",
        "dynamodb:GetItem",
        "dynamodb:Scan",
        "dynamodb:Query",
        "dynamodb:UpdateItem",
        "dynamodb:UpdateTable",
        "dynamodb:GetRecords"
      ],resources:[sdfDynamoDB.tableArn]
    })

      const s3DynamoDBPolicy= new iam.ManagedPolicy(this,'s3Dynamo',{
        managedPolicyName:'s3dynamodbpolicy',
        statements:[s3Statement,dynamoDbStatement],
        description:'for s3Dynamo',
      })

  }
}

AWS Batchの部分

• AWS Batchの部分だけピックアップします
• job定義に設定するロールの設定、コンピューティング環境に設定するインスタンスプロフィールは以下のように作成します。
  • 必要に応じて権限を追加したりしてください。

    // インスタンスのロール S3とDynamoDBへのアクセスを追加
    const instanceRole: iam.IRole = new iam.Role(this, 'InstanceRole', {
      roleName: 'TestInstanceRole',
      assumedBy: new iam.CompositePrincipal(
        new iam.ServicePrincipal('ec2.amazonaws.com'),
      ),

      managedPolicies: [
        iam.ManagedPolicy.fromManagedPolicyArn(
          this,
          'AmazonEC2ContainerServiceforEC2Role',
          'arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role',
        ),
        iam.ManagedPolicy.fromManagedPolicyArn(this,'AwsS3FullAccess','arn:aws:iam::aws:policy/AmazonS3FullAccess'),
        iam.ManagedPolicy.fromManagedPolicyArn(this,'AwsDynamoFullAccess','arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess')
      ],
    });

    // Job用ロールを作成
    const jobRole: iam.IRole = new iam.Role(this, 'JobRole', {
      roleName: 'TestJobRole',
      assumedBy: new iam.CompositePrincipal(
        new iam.ServicePrincipal('ecs-tasks.amazonaws.com'),
      ),
      managedPolicies: [
        iam.ManagedPolicy.fromManagedPolicyArn(
          this,
          'AmazonECSTaskExecutionRolePolicy',
          'arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy',
        ),
      ],
    });

    // インスタンスプロフィールを作成
    const instanceProfile: iam.CfnInstanceProfile = new iam.CfnInstanceProfile(this, 'InstanceProfile', {
      instanceProfileName: 'Testprofile',
      roles: [instanceRole.roleName],

    });

• コンピューティング環境の設定
  • インスタンスのロールやサブネットなどをこちらで設定します。

    // コンピューティング環境を作成
    const computeEnvironment: batch.ComputeEnvironment = new batch.ComputeEnvironment(this, 'BatchCompute', {
      computeEnvironmentName: 'TestComputeEnvironment',
      computeResources: {
        type: batch.ComputeResourceType.ON_DEMAND,
        instanceRole: instanceProfile.attrArn,
        vpc: vpc,
        vpcSubnets: selectSubnets,
        securityGroups: [securityGroup],
      },
      serviceRole:batchRole
    });

• リポジトリの指定
  • 新規でリポジトリを作るところも行う場合は new で作成します。今回はすでにあるリポジトリを使います。

    const repository = Repository.fromRepositoryName(this,'pandastestRepo','pandastest2')
    const ecscontainerImage =  ecs.ContainerImage.fromEcrRepository( repository,'latest')

• JobのキューとJob定義
  • ジョブ定義の時に使用するCPUやメモリなどを指定します、

    // jobのQueを作成
    new batch.JobQueue(this, 'JobQueue', {
      jobQueueName: 'jobQueque',
      computeEnvironments: [{
          computeEnvironment: computeEnvironment,
          order: 1,
      }],
    });

    const jobDefinec = new batch.JobDefinition(this, 'JobDefinition', {
      jobDefinitionName: 'pandasTest',
      container: {
        command: ['1','3','A'],  // コンテナ内で実行されるコマンド
        environment: {'RDS_PASS': 'password','TEST':'ABC'},
        image: ecscontainerImage,
        jobRole: jobRole,
        vcpus: 1,
        memoryLimitMiB: 32,
      },
    });

はじめに

とりあえずAWS IoTを体験してみたい人向けの記事です。
クラウドと自端末を繋げてみる記事です。

環　境

端末
OS：Ubuntu18.04LTS（VMware内で起動）
Python：3.6.9

構築手順

下記手順に従って、クラウド⇔クライアントの通信環境を構築します。

AWS IoTに接続する

AWS IoTにアクセスし、「開始方法」をクリックします。

説明がでてきますが、気にせず「開始方法」をクリック。
相変わらず日本語下手過ぎて、何言ってるか分からないですね。

AWS IoTにどのように接続していますか？

接続機器のプラットフォーム（OS）、接続用のSDKのプログラミング言語を選択します。
今回はUbuntuをクライアントとして利用するので、
プラットフォームは「Linux/OSX」を選択。
SDKはどれでもいいですが、今回は「Python」を選択。
最後に次へを押します。

モノの登録

モノ登録を行います。
適当に「モノ」の名前を付けます。
今回は”test01”にしました。

接続キットのダウンロード

接続キットのダウンロードを行います。
ダウンロードしたファイル（connect_device_package.zip）は端末（今回であればUbuntu）にコピーします。

接続キットには、
・SDK：aws-iot-device-sdk-python
・AWSの証明書：root-CA.crt
・「モノ」用の秘密鍵：test01.private.key
・「モノ」用の公開鍵：test01.public.key
・「モノ」用の証明書：test01.cert.pem
が入っており、至れり尽くせりです。
しかも中のスクリプトファイル（start.sh）を実行するだけで、SDKのインストールからサンプルファイル（basicPubSub.py）の実行までやってくれます。
ちなみにAWSの証明書はリージョン（サーバ群が設置されている国）によって異なりますが、日本リージョン（ap-northeast-1）にアクセスしている場合は勝手に日本リージョンの証明書がダウンロードされます。

デバイスの接続とテスト

まだ完了を押してはいけません。
ダウンロードしたファイルのあるディレクトリで、赤枠のコマンドを順に実行していきます。
他サイトを見ると管理者権限（sudo）でやっている人がいますが、ユーザ権限で大丈夫です。

ただし、多くの場合はライブラリ不足でこけると思います。
自分の場合はAWSIoTPythonSDKフォルダの作成権限がないと怒られました。

error: could not create '/usr/local/lib/python3.6/dist-packages/AWSIoTPythonSDK': Permission denied

実はこのエラー、権限エラーのように見えて、本当はAWSIoTPythonSDKがインストールされていないために起こるエラーです。
下記コマンドを入れて、AWSIoTPythonSDKをインストールすれば直ります。

pip install AWSIoTPythonSDK

もし、pipも入っていない人は次のコマンドでインストールします。

curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
python get-pip.py

参考URL：https://pip.pypa.io/en/stable/installing/

実行に成功すると、Ubuntuのコンソール画面に下記内容が出力されます。
Hello World!がPublishされていることを確認します。

2020-10-11 21:09:20,862 - AWSIoTPythonSDK.core.protocol.internal.clients - DEBUG - Invoking custom event callback...
2020-10-11 21:09:20,862 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Performing sync subscribe...
2020-10-11 21:09:20,862 - AWSIoTPythonSDK.core.protocol.internal.workers - DEBUG - Adding a new subscription record: sdk/test/Python qos: 1
2020-10-11 21:09:20,862 - AWSIoTPythonSDK.core.protocol.internal.clients - DEBUG - Filling in custom suback event callback...
2020-10-11 21:09:20,927 - AWSIoTPythonSDK.core.protocol.internal.workers - DEBUG - Produced [suback] event
2020-10-11 21:09:20,927 - AWSIoTPythonSDK.core.protocol.internal.workers - DEBUG - Dispatching [suback] event
2020-10-11 21:09:20,927 - AWSIoTPythonSDK.core.protocol.internal.clients - DEBUG - Invoking custom event callback...
2020-10-11 21:09:20,927 - AWSIoTPythonSDK.core.protocol.internal.clients - DEBUG - This custom event callback is for pub/sub/unsub, removing it after invocation...
2020-10-11 21:09:22,930 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Performing sync publish...
2020-10-11 21:09:22,930 - AWSIoTPythonSDK.core.protocol.internal.clients - DEBUG - Filling in custom puback (QoS>0) event callback...
2020-10-11 21:09:22,954 - AWSIoTPythonSDK.core.protocol.internal.workers - DEBUG - Produced [puback] event
2020-10-11 21:09:22,955 - AWSIoTPythonSDK.core.protocol.internal.workers - DEBUG - Dispatching [puback] event
2020-10-11 21:09:22,955 - AWSIoTPythonSDK.core.protocol.internal.clients - DEBUG - Invoking custom event callback...
2020-10-11 21:09:22,955 - AWSIoTPythonSDK.core.protocol.internal.clients - DEBUG - This custom event callback is for pub/sub/unsub, removing it after invocation...
2020-10-11 21:09:22,983 - AWSIoTPythonSDK.core.protocol.internal.workers - DEBUG - Produced [message] event
2020-10-11 21:09:22,984 - AWSIoTPythonSDK.core.protocol.internal.workers - DEBUG - Dispatching [message] event
Received a new message: 
b'{"message": "Hello World!", "sequence": 0}'
from topic: 
sdk/test/Python
--------------

IoT機器側でうまくPublishできていると、下記画像のように画面に表示されます。

今度は逆に、クラウドからIoT機器にPublishします。
「ステップ4：デバイスにメッセージを送信する」の枠内に、適当に文字を入力します。
今回は、「Long time no see!」を入れてみました。

「メッセージ送信」クリックします。
うまくいくと、下記内容がstart.shを実行したターミナルに出力されます。

Received a new message: 
b'Long time no see!'
from topic: 
sdk/test/Python
--------------

「完了」を押すと、最後の確認画面が出ます。
気にせず、「完了」を押します。

おつかれさまでした。

まとめ

シンプルなAWS IoTを実装し、クライアント⇔クラウドの通信を体験しました。
次回はセンサー情報をやり取りさせたいと思います。

参考URL

MQTTについて
https://myenigma.hatenablog.com/entry/2019/10/27/194549

AzureもAWSも画像認識の一部の機能がデモ（無料）公開されている。

AzureのFace APIは現時点ではアカウント登録なく誰でも利用可能。「顔検証」を選択する。
https://azure.microsoft.com/ja-jp/services/cognitive-services/face/#demo

AWS Rekognitionはアカウント登録必要。以下のURLでFace comparisonデモが使える。
https://console.aws.amazon.com/rekognition/home

AWSの場合はCelebrity recognitionで有名人と一致するかの確認もできる。

健康不安説や影武者論で情報が錯綜している北朝鮮の金正恩委員長

比較対象の動画のソースとして2019年6月30日の板門店会談と2020年10月10日の朝鮮労働党創建75周年のイベントでの動画から静止画をキャプチャし金正恩委員長が同一人物であるか検証を行った。また、AWSの機能で有名人と一致するのかの確認を行った。
板門店会談：https://www.youtube.com/watch?v=pxb2wITegkM
創建75周年：https://www.youtube.com/watch?v=S3rfsnNva9w

結論　ご本人は健在

AWSとAzureを比較するとAWSの方が同一人物であるとの結果が高くでた。
AWSは99.9%~100%の確率で一致と判断され、Azureの結果では9割程度の確率で同一人物と判断された。

【Azureの結果】
画像比較（～89%一致）：

【AWSの結果】
画像比較（～99.9%一致）：


有名人検索（100%一致）：

言葉巧みなマスコミ、政治的な話に惑わされるのではなく自分自身で調べて真実が何なのかわかるようになってきているのは大きい気がする。
人はAzure, AWSで特定が容易になっている。
音楽についてはYouTubeでアップロードすれば（著作権管理がされていれば）どういう曲なのか直ぐに判明したりする。
お金をかけずに可能になってきていることは知っておいた方がよさそう。

(追記)画像認識に弱点はあるのか？

似通った双子写真には弱い。AWS, Azure共に誤判定が相次ぐ。遺伝子が近い一卵性双生児は見抜くのが困難。兄弟姉妹や親子関係では別人扱いでも双子には弱い。逆の言い方をすると双子は機械的には区別できない同じ顔をしているということになる。これは認識しておこう。

こんにちは！

2回目の投稿になります。

最近はAWSのサービスを用いて、インフラや運用の仕組みを構築することが楽しいです！

記事はこちらに書きました！
是非、これを見て参考になりましたら、幸いです！
https://nekorou.net/aws-inspector-slack/

本記事について

本記事はAWS認定資格SAA(ソリューションアーキテクト アソシエイト)の資格を取得するための学習で調べたキーワードを書き留めるための記事です。
まず初めに軽くではありますがAWSとは何かについて記しておきます。

AWSとは

AWSとはAmazon Web Servicesの略で、Amazonが提供している100以上のクラウドコンピューティングサービスの総称、とググると出てきます。
自分はこの文章では何もわからずちんぷんかんぷんでした...
なのでとりあえずはクラウドコンピューティングとは何か？からみていきます。

クラウドコンピューティング

クラウドコンピューティングとはインターネットを介してサーバー・DB・ストレージ・ソフトウェアなどのコンピュータを使った色々なサービスを意味しています。PCとインターネットさえあれば誰でもサーバーやDB・ストレージなどを利用できるのです！
このたくさんのサービスを提供しているのがAWSという事ですね！

ちなみにクラウドコンピューティングができるまでは、会社の建物内などに直接サーバーを設置して運用する「物理サーバ」を使うやり方をオンプレミスと呼びます。
オンプレミスは時間や費用・場所などの確保が必要となるので、クラウドコンピューティングがとても便利なものかがわかりますね！

代表的なサービス

AWSの代表的なサービスを４つまとめていこうと思います。

EC2

EC2とは「Amazon Elastic Compute Cloud」の略で、簡単にいうとAWS上にサーバーを構築し利用できるサービスです。WEB上でサーバーを持てるという事です！
また、Elasticには伸縮性や弾力性といった意味がありユーザーの必要に応じて変更できることが強みで、スペック不足などの対処も容易であります。
EC2では仮想サーバーのことをインスタンスと呼びます。
インスタンスを複数に分けることで可用性や信頼性を考慮した運用ができます。
仮想サーバーではLinuxやWindowsといったOSが利用可能で、自動的にサーバーの構築とインストールを行ってくれます。
キーペアというインスタンスにログインする際に必要な「秘密鍵」も用意されていて、ログイン情報も安全に管理されています。

また、EC2には3つの料金体制があります。

・オンデマンドインスタンス
サーバーの利用時間によって料金が発生する従量課金のスタイルです。
短時間や限られたタイミングでだけ利用したいときや、試しに仮想サーバーの運用を始める際に適しています。

・リザーブドインスタンス
稼働時間を事前に設定して、料金を先に支払う方法です。
常にインスタンスを利用したいが、予算はオーバーしたくないといったときに役立つでしょう。

・スポットインスタンス
AWS内で使われていないコンピューティングリソースをお得に利用する方法です。
条件はありますが、最大で90％割引で利用できるため、コスト重視での利用を求める場合におすすめされます。

S3

S3とはオンラインストレージや静的なコンテンツを配信することができるサービスです。
イレブンナインというとても高い耐久性を誇り、データ消失の可能性が限りなくゼロに近いと言われています。（ちなみの確率で言うと1,000万年に1度の確率みたいです）
主な機能として「ライフサイクル」、「バージョニング」、「イベント」、「暗号化」、「アクセス権限」、「ログ記録」、「静的Webサイトホスティング機能」があります。
こちらの機能については別の記事で改めて書きたいと思います。

RDS

RDSとはリレーショナル型データベース(関係性データベース)機能を提供するサービスです。
リレーショナル型データベースとは、行と列の2つの軸で表されるデータベースのことで情報の統合性や管理効率化に優れています。
RDSで利用できるRDBMS(Relational DataBase Management Systemの略でデータベースを管理するためのソフトウェア)は「MySQL」、「Postgre SQL」、「Amazon Aurora」、「ORACLE」、「SQL server」、「Maria DB」があります。
詳しくはAWS公式HPを参照してください。
https://aws.amazon.com/jp/rds/

Lambda

LambdaとはサーバーレスのFaaS(Function as a Service：ファース、エフアース)です。
これだけだとちんぷんかんぷんですね...
Faasとはクラウド利用形態の一つでインターネットを通じて、プログラミングで作成した処理を定義・実行するクラウドの利用形態です。要するにサーバーレスの名前の通りサーバーがいらないと言うことですね。本来ならWEBアプリケーションを運用管理するには、サーバーやミドルウェアも管理しないといけないのですが、LambdaはそれらをAWSが行ってくれるのです。なので運用管理を行う必要がなく、アプリケーションやプログラムコードだけを作成すれば、Webアプリケーションを公開できるようになります。

AWSのメリット・デメリット

AWSのメリットとデメリットについてまとめます。

メリット

1. 費用面
   ハードウェア・ソフトウェアの購入が不要で従量課金制のため定額制とは違い無駄だコストを抑えられます。

2. セキュリティ
   常に最新のセキュアが施され、第三者機関認証も利用できます。

3. 拡張性
   メモリやストレージなどの拡張が簡単に行えます。

4.俊敏性
PCとインターネット環境さえあればできるので手軽に素早く利用できます。

5.場所
物理的なサーバーが不要なので場所を確保する必要がありません。

デメリット

1.費用面
従量課金制のため費用の予算が組みづらいです。

2.　サービスの理解
サービスの種類が多すぎて(100種類以上)、全てを把握するのが難しいです。

　まとめ

とりあえず簡単ではありますがAWSとは何かを自分なりに描いてみました。
詳しく書くとキリがないので省いてしまった部分もありますが誰かのためになると嬉しいです。

※ここ間違ってる！などありましたらコメントいただけると幸いです。

事象

Capistranoでのデプロイ時、CircleCI仮想環境からEC2へのSSH接続に失敗する

Net::SSH::AuthenticationFailed: Authentication failed for user *****@*************

前提

CircleCIの導入については以下の記事を参考にさせていただいたので、
記事の内容通りに実施してSSHが失敗したという前提で進めていきます。

CircleCI + Capistrano + AWS(EC2) + Railsで自動デプロイしてみた

結論

CircleCIに設定していた環境変数（PRODUCTION_SSH_KEY）が誤っておりました。
.circleci/config.yml内の記述-add_ssh_keys:によって、
CircleCIのコンテナ上に作成される秘密鍵の名称は「id_rsa_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX」であるため、
CircleCIに設定する環境変数は、「id_rsa_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX」が正解でした。
筆者はここで約2日悩まされることになりました。笑
※「XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX」の部分はfingerprintsの：なし文字列

詳細

筆者は以下のようにCircleCIに環境変数（PRODUCTION_SSH_KEY）を設定しておりました。
「~/.ssh/hoge_rsa_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX」
※hoge_rsaはローカルからEC2へSSH接続するための秘密鍵

原因調査のために、CircleCIコンテナにSSH接続。
※CircleCIコンテナへのSSH接続については公式ドキュメント「SSH を使用したデバッグ」をご参照ください

~/.sshディレクトリを覗いてみると、、、

！！！！！！！！！！！！！！！！！！！！！！！！

id_rsa_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

だと、、、
「hoge_rsa_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX」じゃない、、、
まさか、、、

というわけでCircleCIの環境変数（PRODUCTION_SSH_KEY）に
「id_rsa_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX」を設定し直したところ、
無事にCircleCI仮想環境からEC2へのSSH接続およびCapistranoでの自動デプロイに成功しました。?

事象

Capistranoでのデプロイ時、CircleCI仮想環境からEC2へのSSH接続に失敗する

Net::SSH::AuthenticationFailed: Authentication failed for user *****@*************

前提

CircleCIの導入については以下の記事を参考にさせていただいたので、
記事の内容通りに実施してSSHが失敗したという前提で進めていきます。

CircleCI + Capistrano + AWS(EC2) + Railsで自動デプロイしてみた

結論

CircleCIに設定していた環境変数（PRODUCTION_SSH_KEY）が誤っておりました。
.circleci/config.yml内の記述-add_ssh_keys:によって、
CircleCIのコンテナ上に作成される秘密鍵の名称は「id_rsa_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX」であるため、
CircleCIに設定する環境変数は、「id_rsa_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX」が正解でした。
筆者はここで約2日悩まされることになりました。笑
※「XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX」の部分はfingerprintsの：なし文字列

詳細

筆者は以下のようにCircleCIに環境変数（PRODUCTION_SSH_KEY）を設定しておりました。
「~/.ssh/hoge_rsa_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX」
※hoge_rsaはローカルからEC2へSSH接続するための秘密鍵

原因調査のために、CircleCIコンテナにSSH接続。
※CircleCIコンテナへのSSH接続については公式ドキュメント「SSH を使用したデバッグ」をご参照ください

~/.sshディレクトリを覗いてみると、、、

！！！！！！！！！！！！！！！！！！！！！！！！

id_rsa_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

だと、、、
「hoge_rsa_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX」じゃない、、、
まさか、、、

というわけでCircleCIの環境変数（PRODUCTION_SSH_KEY）に
「id_rsa_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX」を設定し直したところ、
無事にCircleCI仮想環境からEC2へのSSH接続およびCapistranoでの自動デプロイに成功しました。?

公式の試験ガイドを元にまとめてみました。投稿時点の情報です。
参考：https://aws.amazon.com/jp/certification/

試験コード	試験名	合格ライン	試験時間	受験料金（税別） 本試験／模擬試験
CLF-C01	AWS Certified Cloud Practitioner AWS 認定 クラウドプラクティショナー	700点（67%）	90 分	11,000 円／2,000 円
SAA-C02	AWS Certified Solutions Architect - Associate AWS 認定 ソリューションアーキテクト - アソシエイト	720点（69%）	130 分	15,000 円／2,000 円
SOA-C01	AWS Certified SysOps Administrator - Associate AWS 認定 SysOps アドミニストレーター – アソシエイト	720点（69%）	130 分	15,000 円／2,000 円
DVA-C01	AWS Certified Developer - Associate AWS 認定 デベロッパー – アソシエイト	720点（69%）	130 分	15,000 円／2,000 円
SAP-C01	AWS Certified Solutions Architect - Professional AWS 認定 ソリューションアーキテクト － プロフェッショナル	750点（72%）	180 分	30,000 円／4,000 円
DOP-C01	AWS Certified DevOps Engineer - Professional AWS 認定 DevOps エンジニア - プロフェッショナル	750点（72%）	180 分	30,000 円／4,000 円
ANS-C00	AWS Certified Advanced Networking - Specialty AWS 認定 高度なネットワーキング – 専門知識	非公開	170 分	30,000 円／ 未提供
DAS-C01	AWS Certified Data Analytics - Specialty AWS 認定 データアナリティクス – 専門知識	750点（72%）	180 分	30,000 円／4,000 円
SCS-C01	AWS Certified Security - Specialty AWS 認定 セキュリティ – 専門知識	750点（72%）	170 分	30,000 円／4,000 円
MLS-C01	AWS Certified Machine Learning - Specialty AWS 認定 機械学習 – 専門知識	750点（72%）	180 分	30,000 円／4,000 円
AXS-C01	AWS Certified Alexa Skill Builder - Specialty AWS 認定 Alexa スキルビルダー – 専門知識	750点（72%）	170 分	30,000 円／4,000 円
DBS-C01	AWS Certified Database - Specialty AWS 認定 データベース – 専門知識	750点（72%）	180 分	30,000 円／4,000 円

試験コード	試験名	対象や推奨されるAWS知識・IT全般の知識など
CLF-C01	AWS Certified Cloud Practitioner AWS 認定 クラウドプラクティショナー	- テクノロジー、マネジメント、販売、購買、またはファイナンスの分野で最低 6 か月の AWS クラウド使用経験 - IT サービスのベーシックな知識と、AWS クラウドプラットフォームにおけるそれらのサービスの使用に関する知識　等
SAA-C02	AWS Certified Solutions Architect - Associate AWS 認定 ソリューションアーキテクト - アソシエイト	- AWS における分散システムの可用性、コスト効率、高耐障害性およびスケーラビリティの設計に関する1 年以上の実務経験　等
SOA-C01	AWS Certified SysOps Administrator - Associate AWS 認定 SysOps アドミニストレーター – アソシエイト	- AWS における開発、管理、運用に関する少なくとも 1 年以上の経験 - システムの運用を担当するシステム管理者としての１～2 年の経験　等
DVA-C01	AWS Certified Developer - Associate AWS 認定 デベロッパー – アソシエイト	- AWS ベースのアプリケーションの開発や保守における1 年以上の実務経験　等
SAP-C01	AWS Certified Solutions Architect - Professional AWS 認定 ソリューションアーキテクト － プロフェッショナル	- AWS におけるシステムの管理および運用に関する2 年以上の実務経験 - AWS でのクラウドアーキテクチャの設計およびデプロイに関する2 年以上の実践経験　等
DOP-C01	AWS Certified DevOps Engineer - Professional AWS 認定 DevOps エンジニア - プロフェッショナル	- AWS 環境のプロビジョニング、運用、管理において2 年以上の経験　等
ANS-C00	AWS Certified Advanced Networking - Specialty AWS 認定 高度なネットワーキング – 専門知識	- AWS のネットワークの概念と技術に関する高度な知識 - ネットワークソリューションのアーキテクチャの設計と実装における5 年以上の実務経験　等
DAS-C01	AWS Certified Data Analytics - Specialty AWS 認定 データアナリティクス – 専門知識	- AWS データレイクおよび分析サービスの専門知識 - 一般的なデータ分析テクノロジーに関する5 年以上の経験 - AWS を使用した2 年以上の実務経験　等
SCS-C01	AWS Certified Security - Specialty AWS 認定 セキュリティ – 専門知識	- 最低 2 年間の AWS のワークロードの保護に関する実務経験 - セキュリティソリューションの設計や実装に関する5 年以上の IT セキュリティに関する経験 - AWS のワークロードのセキュリティ保護に関する2 年以上の実務経験　等
MLS-C01	AWS Certified Machine Learning - Specialty AWS 認定 機械学習 – 専門知識	- 与えられたビジネス上の問題に対する機械学習ソリューションを設計、実装、デプロイ、維持する能力 - AWS クラウドにおける ML/ディープラーニングのワークロードの開発、アーキテクチャ設計、運用に関する1 ～ 2 年以上の実務経験　等
AXS-C01	AWS Certified Alexa Skill Builder - Specialty AWS 認定 Alexa スキルビルダー – 専門知識	- Alexa Skills Kit と AWS のクラウドサービスを使用して、Alexa スキルを作成した6 か月以上の実務経験　等
DBS-C01	AWS Certified Database - Specialty AWS 認定 データベース – 専門知識	- 一般的なデータベーステクノロジーを使用した5 年以上の経験 - AWS に関する2 年以上の実務経験　等

はじめに

今日（10/11）に「AWS Certified Database - Specialty」資格（以降DBS）に受かりました。
個人的にはANS（Network）やSAPほど難しい試験ではないと思っていましたが、スコア的にはぎりぎりだったので、1/2まで絞り込んでどっちかわからない、という問題を落としまくったのだと思います（それでも簡単な部類に入る試験だと思っていますが）
誰かの役に立てば幸いです。

※過去の記事
AWS SAAに受かった話
AWS SOAに受かった話
AWS DVA(とCLP)に受かった話
AWS SAPに受かった話
AWS SCSに受かった話
AWS ANSに受かった話

獲得スコア

受験日	スコア/合格点/満点	結果
2020/10/11	756/750/1000	合格

勉強に使った教材

※いつものようにBlackbeltとWhizlabsは省略

AWS Summit 2020/2019資料

AWS SummitではDB関連のセッションが豊富なので、Auroraはそれなりに知っていてもDynamoDBのことはよくわからない人（＝自分）はセッション動画を1.5倍速で流すだけでもかなり勉強になります。
（自分はDynamoDBとDBマイグレーションのセッションを何回か見直しました）

AWS Summit 2020セッション一覧
AWS Summit 2019セッション一覧

Amazon RDS Online Seminar

Auroraを詳しく勉強したい人は、9/10のオンラインセミナー資料と動画が公開されています。
試験ではAuroraのアーキテクチャーを知っている前提の問題が出るので、こちらも非常に参考になりました。
（RDSプロキシは範囲外だと思いますが、実務としては使えるので損はないかと）

https://aws.amazon.com/jp/blogs/news/amazon-rds-online-seminar1-qa-202009/

試験の所感

• 簡単な問題と難しい問題が混在しており、難易度はかなりばらつきがある
  • 簡単な問題を拾うだけでも合格する可能性まである？
• 問題はAuroraとRDSとDynamoDBが8割ぐらい
• Elasticacheもそれなりに出る
• AuroraとDynamoDBはかなり突っ込んだ問題が出るので、固有の機能は理解しておく
• AuroraとRDSでできること・できないことの違いは把握しておく
  • RDSの場合はDBエンジンの違いも（移行時の制約など）
• Neptune、QLDB、DocumentDBも概要ぐらいは覚えておく
• DB移行は要件ごとに適切な機能・サービスを選べるようにしておく
• 忘れた頃にCloudformation
  • ただしそこまで深くは聞かれない
• DBの認証情報管理をどこに持たせるか問題
  • アプリやCfnのコードに直接書くのはベストプラクティス的に論外なので、IAM認証やSecret Managerなどで管理

概要

悩み

• エンジニアMac(MacBookPro:i7,Mem16GB)が火を吹いてて辛い
  • オンライ会議ソフト(zoom)や、オンライホワイトボード(miro)など、重量級のソフトCPUを食い潰すようになった
  • サーバサイドエンジニア(Rails/AWS)のMacでは各種開発用サーバをdockerで動かしているが、
    もともと重かったdockerと相まって笑えるほど遅い

やりたいこと

• Macの負荷を下げるため、手元のMacからできるだけプロセスを外部のサーバに(AWS EC2)に投げたい。

不安と期待

• 今までローカルで完結してた開発環境をリモートに切り離すにはいろいろ不安がある、 またはリモートだからこその期待がある。
  • 快適に開発できるのか
    • 「sshでつなげてVimで開発は流石に嫌だよ？ VSCode 使いたい」
  • 安全に開発できるのか
    • 「通信ダダ漏れとかありえない」
  • 自由にどこでも開発できるようになるのか
    • 「カフエとかドーナツ屋さんで仕事したい」
  • 自由にどんな端末でも開発できるようになるのか
    • 「旅行にパソコン持って行きたくない！！！、ipadとかスマホで仕事したい！！」
  • 無駄なコストが発生しないか
    • 「使ってない月に、ン万円以上コストがかかるのは生理的に無理」

計画

フェーズ分け

• いきなり全部やるとしんどそうだったので、以下のようにフェーズ分けしてます。

  • Phase1. 予め決まった拠点(オフィス、家など)から、PCで開発環境につなぐ
  • Phase2. 任意の場所から、PCで開発環境につなぐ
  • Phase3. 任意の場所から、任意の(自身の）端末で開発環境につなぐ
  • Phase4. コスト最適化
    • ?

この記事は

• 現在進行形の「ここはこうしよう」、「ここはこうしようかな」というメモを晒している記事です。

構成設計・調査メモ

• 選定した内容、選定した意図、簡単な比較、設定内容など

構成: Phase1

• 概要
  • 普段の開発環境から、開発用サーバ(docker)とVSCodeのCPU負荷をEC2に追い出すことができた
  • コスト: 月$20ほど
  • インフラ: 主にAWS(Route53,EC2など)を使用
  • IDE: VSCode Remote Development
  • 独自ドメイン
  • 通信を暗号化(SSH/HTTPS)

リモートサーバ

• 必須条件
  • SSH可能 -> Linux
  • 公開できる -> ドメイン繋げられる(HTTPS)
• 歓迎条件
  • コストを抑えられる、抑える手段がある

• 結論: AWS EC2
  

  • 必要なときは性能のスケールアウトが可能
    • ただし一旦停止は必要
  • spot instanceでコストを抑えられる
    • vCPU:2,Mem:4GB (t3.medium)で 月大体$15ほど
      • (インスタンス稼働コスト+ストレージなど諸費用)
  • この記事を書いた人が慣れているため * 仕事でAWS使ってる人多いすよね。。。

• 他の選択肢

  • クラウド系
    • GCP,Azureなど
  • VPS系
    • さくらのVPSなど

• 設定内容

  • security groupの設定
    • HTTPS: 「マイIP」で予め決まった拠点(オフィス、家など)のIPアドレスを設定する
    • SSH: 「マイIP」で予め決まった拠点(オフィス、家など)のIPアドレスを設定する

リモート開発環境

• 必須条件
  • コードの編集・実行ができる
  • クライアントとサーバが暗号通信すること
• 歓迎条件
  • プラグインが豊富で活発
  • ブラウザだけで動くと尚良
    

• 結論: VSCode + Remote Developmentプラグイン
  

  • VSCodeはいわずもがな2020年のサーバサイド開発のスタンダードになってるIDE
  • Remote DevelopmentはSSHした先のLinuxサーバ上でIDEを実行できる機能

• 他の選択肢

  • WebIDE系
    • AWS Cloud9

暗号通信

• 必須条件
  • WEBへアクセスできること(HTTPS)
  • SSH
• 歓迎条件
  • 手間を書けたくない
  • コスト抑えたい

• 結論

  • freenom(独自ドメイン) +　Route53(DNS) + Caddy(HTTPS Webサーバ)

    • freenom: 無料ドメイン

      • 特定のTLDなら無料でドメインが取れる
      • Ref: freenomでドメインの取得

      1 .tk オーストララシアにあるニュージーランドの領土であるトケラウ
      2 .ml マリ
      3 .ga ガボン
      4 .cf 中央アフリカ
      5 .gq 赤道ギニア

    • Route53

      • ドメインのDNS管理
      • 実質ほぼ無料

    • Caddy

      • Web サーバー
      • ドメインがあれば自動でHTTPS通信になる
        • 簡単にSSL証明書を取得可能＆シンプルな設定ファイルでHTTP/3も利用できるGo製ウェブサーバー「Caddy」！
      • basic 認証設定可能

• 他の選択肢

  • VSCodeのポートファワーディング
    • Ref: VSCode Remote Development + SSHトンネルで安全なWebアプリケーション開発
    • 開発をポートフォワードが自由に行える環境:PCだけで行うのであれば構わないが、
      iPadなどのモバイル端末ではこの手法が使えない
  • AWS ALB + AWS Route 53
    • Route53+ACM+ALB+EC2でHTTPS接続するまで
    • 高い: ALBだけで月$25ほど

[WIP] VPN

• 必須条件
  • クライアントの通信内容を全て暗号化したい
  • 新しい場所:新しいIPから接続するときに、ファイアウォール(SecurityGroup)をいちいち追加・削除したくない
• 歓迎条件
  • 動作・通信速度が早い
  • スマホ、タブレットなど様々な端末でも接続可能
    • 例: iPad/android/ChromeOS
• 調査
  • wireguardが良さげ
    • 動作・通信が早く、インストールが簡単らしい
      • 第614回　WireGuardでVPNサーバーを構築する
    • Mac/Windows/Linux/iOS/Androidに対応
      • https://www.wireguard.com/install/
      • ChromeOSはAndroid用アプリが使えるらしい
        • Add docs that cover using Wireguard from ChromeOS

[WIP] いつでも開発するために

• 必須条件
  • Windows/Mac/ChromeOS/Android/iOSで稼働すること

• 歓迎条件

  • ブラウザのみで稼働する
    • OculusQuestとか独自カスタマイズ系のOSでも開発できると嬉しい

• 調査中

  • VSCode Onlineに「開発環境サーバ」をSelf-hosted環境としてつなぐ
    • 「Visual Studio Online」をSelf-hosted環境で使う
      • △: サーバにVS Code自体のインストールが必要
        • デスクトップ環境(Gnome/LXDE)のインストールが必要
      • △: VSCode Online(codespaces)が GitHub Codespaceに統合されるようで、先行きがよくわからない
        • マイクロソフト、WebIDEの「Visual Studio Codespaecs」を「GitHub Codespaces」に統合へ
  • code server
    • サードパーティ製のVSCodeをWebサーバ化したもの
    • △: 使えるプラグインが限定される
      • Visual Studio Intellicodeとか使えない

[WIP]起動していないときにサーバを止める

• herokuみたいなことをしたい
  • 「踏み台サーバ」へSSH portfowardingの接続要求が発生
  • 認証完了
  • 「踏み台サーバ」は「開発環境サーバ」を起動する
    • 30秒ぐらい？
  • 接続する

はじめに

• Splunkを使ったFraud（不正）監視のユースケースは多い
• 特にWebサービスはECサイトをはじめ、不正ログインまたはATO（アカウントテイクオーバー）のリスクに常にさらされており、2要素認証が完全普及してない状況からも常に被害報告が出ている

• そのような状況で、できうる対策としてアカウント認証の異常パターンをモニタリングすることがポイントになってくる
• が、モニタリングの仕組みを実現する上で大きな２つの課題をよく耳にする
  • アプリケーションから認証ログが出力されていない
  • 監視ルール作りや監視体制が整っていない

Oops...アプリケーションから認証ログが出力されていない

• 必要なデータがない。これでは監視のスタートにたてない・・・アプリケーションの改修も簡単ではない。
• そのような状況に対して、本記事ではアプリケーションを改修しないでWeb(http) トラフィックのStreamデータからデータを取り出し、Splunkで分析する方法を以前紹介
• AWSのVPC Traffic Mirroringを利用して、AWSのEC2インスタンス（webサーバ）に流れるhttpトラフィックをSplunk Streamでキャプチャしました
  • (VPC Traffic MirroringってVPC Flowのことかと思っていたらFlowデータではなかった。)

構成イメージ

• Webサーバを1から作らなくてもWebサーバみたいなログイン認証データが取れるSplunkを使って検証しました
• AWS MarketPlaceからポチッとインスタンスを2つ作成
  • Nitro世代のm5a.largeのインスタンスを利用。

設定手順(AWS VPC Traffic Mirroring)

• AWSのVPC Traffic Mirroringの設定方法は以下記事が大変参考になりました
  • VPC Traffic Mirroring を使ってみる
• 上記Blogを参考にして設定します。補足ポイントを以下に記載
  • VPC Traffic Mirroringを受け取るSplunkサーバには拡張NIC(eth1)をつけて、Traffic MirrorをSplunkサーバのeth1に流す
  • SplunkサーバにアタッチするセキュリティグループのinboundポリシーにUDP port 4789を加える
  • Traffic Filter Policyの設定例（アウトバウンドデータ（webのレスポンスデータ）もミラー対象にしていないとStream分析に支障をきたします）

Inbound

Outbound

• Outboundルールはもう少し絞れたら絞ったほうがいいかもしれませんが、Splunk Stream側で分析対象のトラフィックはいかようにも調整できるのでこれでもOKです。

設定手順(Splunk Stream)

• Splunkには以下Appsをインストール。Stream Appsも以前は1つにまとまっていましたが、最近細かく分けた模様

• Splunkサーバに以下Appsをすべてインストール

  • Splunk App for Stream
    • Forwarder management, dashboards, calculators and admin tools
  • Splunk Add-on for Stream Wire Data
    • Knowledge objects for parsing Stream data for use by users. Installed on Indexers and Search Heads.
  • Splunk Add-on for Stream Forwarders
    • Network data collection tools for capturing network data, interpreting protocols, extracting custom fields and sending to Splunk. Installed on Splunk Universal or Heavy Forwarders.

• Stream Appの初期セットアップ

  • Installation and Configuration Manual

shell

・パーミション設定
cd /opt/splunk/etc/apps/Splunk_TA_stream
sudo chmod +x ./set_permissions.sh
sudo ./set_permissions.sh

・SplunkサーバにSSHアクセスして以下configを編集し、eth1に入ってくるパケットをstreamのキャプチャ対象にする（デフォルトだとeth0しか見ていない
vi /opt/splunk/etc/apps/Splunk_TA_stream/local/streamfwd.conf 

[streamfwd]
streamfwdcapture.<N>.interfaceRegex = eth1
streamfwdcapture.<N>.offline = false

• GUIからにhttpプロトコル内の取得フィールドを細かく選択
  • Splunk Streamのいいところ。柔軟に収集したいフィールドを設定できる。 -

結果

• Webサーバに対するhttpトラフィックがキャプチャできています

• form_dataにはログインアカウント名とパスワード文字列までばっちり見えます

• 少なくともログイン時のアカウント名と認証成功か失敗だけでも見れればOKですね。
  

• IDとパスワードは正規表現で後からスキーマ定義（Scheme on the read!!）

SPL

|rex field=form_data "username=(?<user>[^&|^$]+)"
|rex field=form_data "password=(?<password>[^&|^$]+)"

はまったポイント

• VPC Traffic Mirroringのフィルター条件にinboundのみ設定
  • Splunk Streamでhttpトラフィックは可視化できるのだが、なぜか実トラフィック発生からindexされるまでに5分近くかかっていた。
  • 不審におもいoutboundも転送対象にした所、数秒以内でログ検索できるようになった。httpレスポンスも見て解析しているので片方だけの解析によって処理が遅くなっていたのだと思われる

次回について

• せっかく集めたデータを活用するためのAppsを紹介します！

参考記事

• これらの丁寧な日本語記事のおかげですんなり設定できました。感謝。
  • VPC Traffic Mirroring を使ってみる
  • 【初心者】AWS VPC Traffic Mirroring を使ってみる

はじめに

Golangってめちゃくちゃ高速だし最高！という話があるものの、Webフレームワークを扱うにあたっては、まだまだ情報も事例も少ないという状況で、実際に高速とは言え実運用に持ち込むにはリスクがあるかもしれない。
一方で、SpringBootはWebフレームワークとしては充分に実績があるので、速度差次第では充分に採用するメリットはある。

というわけで、今回は「実際にどれくらい速度違うの？」というのを確かめてみた。

条件としては

• DynamoDBから1アイテムをGetItemするトラフィックをかける
• DynamoDBへのアクセスはVPCエンドポイント経由
• FargateのCPU割り当てを256ユニット→512ユニットで垂直スケールするかを確認する(水平スケールは充分に実績がある前提として確認しない)
• GolangのWebフレームワークはGinを使用
• GolangのSDKはv2を使用(プレビューだが、v1は全然スループットが出なかった)

といったところか。

なお、測定ツールにはlocustを用いていて、画面キャプチャを使っているので、各項目の目盛りのスケールがあっていないのはご了承いただきたい……。

Golang編

256CPUユニット

10ユーザ単位で増加させた。
スループットは最大で250rps程度。
それを超えると、CPUが高騰してスループットが激減する。300rpsは安定しなそう。

上記の時間帯のCloudWatchメトリクスのCPU Utilizationは以下。

512CPUユニット

20ユーザ単位で増加させた。
スループットは最大で440rps程度。
それを超えると、CPUが高騰してスループットが激減する。

CPUユニット数を倍にしているのにスループットが倍にならず垂直スケールしないのが謎。
AWS Go SDK v1でもv2でこの傾向は同じだが、v2の方がCPUユニットあたりのスループットは出る。

上記の時間帯のCloudWatchメトリクスのCPU Utilizationは以下。

Java編

256CPUユニット

JavaはJavaでなかなか安定しないグラフになる。
20ユーザ単位で増加させた。
スループットは最大で450rps程度出ているが、このタイミングでは95%タイルや中央値が悪化しているので、安定を目指すなら380rps程度出ているポイントを目指すべきだろう。

上記の時間帯のCloudWatchメトリクスのCPU Utilizationは以下。
380rpsのポイントでもCPUは80%以上使えているので、まずまず充分に使えている。

512CPUユニット

やっぱりこちらも安定しない。
80rpsをスタートにして、20ユーザ単位で増加させた。
Ginと違い、こちらは垂直にスケールしている。だいたい850rpsを超えると95%タイルが悪化しているので、このあたりのポイントが良いだろう。この時点でのCPU使用率は80%以上なので、こちらも充分に使いきれてると言える。

上記の時間帯のCloudWatchメトリクスのCPU Utilizationは以下。

結論

Ginの方がトラフィックが安定するものの、垂直スケールしない点が気になる。
SpringBootについては、スレッド数やGC頻度を調整すればもう少し安定しそう。
もうちょっと実績が出てドキュメントが増えればGinは全然アリだが、現時点では何かがあっても調べようがないのが厳しいところだ。

せっかく調べたので忘れないようにメモ

aws command not foundと言われたので

aws-cliをインストール

$ sudo pip install awscli

コマンドが使えるようになったので初期設定

$ aws configure --profile [好きな名前]

アクセスキーとシークレットアクセスキーはIdentity and Access Management (IAM)から確認できる

AWS Access Key ID [None]: {アクセスキー(各自)}
AWS Secret Access Key [None]: {シークレットアクセスキー(各自)}
Default region name [None]: ap-northeast-1
Default output format [None]: json

確認
[好きな名前]＝[さっき決めた名前]

$ aws configure list --profile [好きな名前]

デフォルトを[好きな名前]に変更

$ export AWS_PROFILE=[好きな名前]

$ aws configure list

あとはPush commandsをうつだけ！

参考

AWS CLIの認証設定をする際の注意
AWS-CLIの初期設定のメモ

せっかく調べたので忘れないようにメモ

aws command not foundと言われたので

aws-cliをインストール

$ sudo pip install awscli

コマンドが使えるようになったので初期設定

$ aws configure --profile [好きな名前]

アクセスキーとシークレットアクセスキーはIdentity and Access Management (IAM)から確認できる

AWS Access Key ID [None]: {アクセスキー(各自)}
AWS Secret Access Key [None]: {シークレットアクセスキー(各自)}
Default region name [None]: ap-northeast-1
Default output format [None]: json

確認
[好きな名前]＝[さっき決めた名前]

$ aws configure list --profile [好きな名前]

デフォルトを[好きな名前]に変更

$ export AWS_PROFILE=[好きな名前]

$ aws configure list

あとはPush commandsをうつだけ！

参考

AWS CLIの認証設定をする際の注意
AWS-CLIの初期設定のメモ

概要

・自分が詰まったポイントと同じポイントで詰まった方向けにAWSにlaravel/dockerをデプロイするまでの過程を書いていきます。

EC2インスタンス内にGitをクローン

Gitのリモートレポジトリにある任意のlaravelプロジェクトをEC2インスタンス内にクローンします。

root@ip:/home/ubuntu# git clone [任意のレポジトリURL]

Dockerコンテナの立ち上げ

cloneした自分のフォルダ(docker-compose.ymlのある)へ移動し、コンテナを立ち上げます。

root@ip:/home/ubuntu/awstest# docker-compose up -d
root@ip:/home/ubuntu/awstest# docker-compose ps
    Name                   Command               State           Ports        
------------------------------------------------------------------------------
awstest_app_1   docker-php-entrypoint php-fpm    Up      9000/tcp             
awstest_db_1    docker-entrypoint.sh mysqld      Up      3306/tcp, 33060/tcp  
awstest_web_1   /docker-entrypoint.sh ngin ...   Up      0.0.0.0:10080->80/tcp

この様に立ち上がればOKです。

苦戦した箇所
docker-compose.ymlのバージョンエラーが出てエラー内容通り

root@ip-172-31-35-36:/home/ubuntu/awstest# vi docker-compose.yml
version: "3.3" ←3.8から3.3に変更

とversionを変更しました。
さらにgitへのpushが間違っていた為docker関連のファイルが無く立ち上がりませんでした。
こんなミスするヤツ自分以外いないと思いますが万が一同じ人がいたらファイルの確認をしてみて下さい。

Laravel環境設定

Laravelが使えるように環境設定をしていきます。
appコンテナに入ります。

root@ip:/home/ubuntu/awstest# docker-compose exec app bash

Laravelプロジェクト内の環境設定を行う.envファイルは.gitignoreにて指定されているため、Gitリポジトリにプッシュされません。
なので再度作成します。

root@:/work# cp .env.example .env

.envを作成したらcomposer install、そしてAPP_KEYも発行します。

root@:/work# composer install

root@:/work# php artisan key:generate

プロジェクト内の権限変更

プロジェクト内のファイルに対する権限を変更します。

通常では storage/logs と vendor の権限を変更すればOKみたいです。

ここでもエラーが起き少し苦戦しました。

file_put_contentsエラーでViewが開かない

root@:/work# chmod 777 storage/logs vendor
root@:/work# chmod 777 storage/framework/views
root@:/work# chmod 777 storage/framework/sessions

ここまでやってようやくTOPページが開ました。

http://[設定したElastic IPアドレス]:10080にブラウザからアクセスします。

この様に表示されればOKです。

前回の記事
AWSにdockerを使用したlaravelをデプロイ③

＊＊間違い等ございましたらご指摘お願い致します＊＊

概要

・自分が詰まったポイントと同じポイントで詰まった方向けにAWSにlaravel/dockerをデプロイするまでの過程を書いていきます。

EC2インスタンス内にGitをクローン

Gitのリモートレポジトリにある任意のlaravelプロジェクトをEC2インスタンス内にクローンします。

root@ip:/home/ubuntu# git clone [任意のレポジトリURL]

Dockerコンテナの立ち上げ

cloneした自分のフォルダ(docker-compose.ymlのある)へ移動し、コンテナを立ち上げます。

root@ip:/home/ubuntu/awstest# docker-compose up -d
root@ip:/home/ubuntu/awstest# docker-compose ps
    Name                   Command               State           Ports        
------------------------------------------------------------------------------
awstest_app_1   docker-php-entrypoint php-fpm    Up      9000/tcp             
awstest_db_1    docker-entrypoint.sh mysqld      Up      3306/tcp, 33060/tcp  
awstest_web_1   /docker-entrypoint.sh ngin ...   Up      0.0.0.0:10080->80/tcp

この様に立ち上がればOKです。

苦戦した箇所
docker-compose.ymlのバージョンエラーが出てエラー内容通り

root@ip-172-31-35-36:/home/ubuntu/awstest# vi docker-compose.yml
version: "3.3" ←3.8から3.3に変更

とversionを変更しました。
さらにgitへのpushが間違っていた為docker関連のファイルが無く立ち上がりませんでした。
こんなミスするヤツ自分以外いないと思いますが万が一同じ人がいたらファイルの確認をしてみて下さい。

Laravel環境設定

Laravelが使えるように環境設定をしていきます。
appコンテナに入ります。

root@ip:/home/ubuntu/awstest# docker-compose exec app bash

Laravelプロジェクト内の環境設定を行う.envファイルは.gitignoreにて指定されているため、Gitリポジトリにプッシュされません。
なので再度作成します。

root@:/work# cp .env.example .env

.envを作成したらcomposer install、そしてAPP_KEYも発行します。

root@:/work# composer install

root@:/work# php artisan key:generate

プロジェクト内の権限変更

プロジェクト内のファイルに対する権限を変更します。

通常では storage/logs と vendor の権限を変更すればOKみたいです。

ここでもエラーが起き少し苦戦しました。

file_put_contentsエラーでViewが開かない

root@:/work# chmod 777 storage/logs vendor
root@:/work# chmod 777 storage/framework/views
root@:/work# chmod 777 storage/framework/sessions

ここまでやってようやくTOPページが開ました。

http://[設定したElastic IPアドレス]:10080にブラウザからアクセスします。

この様に表示されればOKです。

マイグレーションを実行する

root@:/work# php artisan migrate
root@:/work# php aritsan db:seed

ここまでやればローカルで作成したアプリが動くと思います。

以上で「AWSにEC2上にdockerを使用したlaravelをデプロイ」を終了させていただきます。
ありがとうございました。

前回の記事
AWSにEC2上にdockerを使用したlaravelをデプロイ③

＊＊間違い等ございましたらご指摘お願い致します＊＊

概要

・自分が詰まったポイントと同じポイントで詰まった方向けにAWSにlaravel/dockerをデプロイするまでの過程を書いていきます。

EC2インスタンス内にGitをクローン

Gitのリモートレポジトリにある任意のlaravelプロジェクトをEC2インスタンス内にクローンします。

root@ip:/home/ubuntu# git clone [任意のレポジトリURL]

Dockerコンテナの立ち上げ

cloneした自分のフォルダ(docker-compose.ymlのある)へ移動し、コンテナを立ち上げます。

root@ip:/home/ubuntu/awstest# docker-compose up -d
root@ip:/home/ubuntu/awstest# docker-compose ps
    Name                   Command               State           Ports        
------------------------------------------------------------------------------
awstest_app_1   docker-php-entrypoint php-fpm    Up      9000/tcp             
awstest_db_1    docker-entrypoint.sh mysqld      Up      3306/tcp, 33060/tcp  
awstest_web_1   /docker-entrypoint.sh ngin ...   Up      0.0.0.0:10080->80/tcp

この様に立ち上がればOKです。

苦戦した箇所
docker-compose.ymlのバージョンエラーが出てエラー内容通り

root@ip-172-31-35-36:/home/ubuntu/awstest# vi docker-compose.yml
version: "3.3" ←3.8から3.3に変更

とversionを変更しました。
さらにgitへのpushが間違っていた為docker関連のファイルが無く立ち上がりませんでした。
こんなミスするヤツ自分以外いないと思いますが万が一同じ人がいたらファイルの確認をしてみて下さい。

Laravel環境設定

Laravelが使えるように環境設定をしていきます。
appコンテナに入ります。

root@ip:/home/ubuntu/awstest# docker-compose exec app bash

Laravelプロジェクト内の環境設定を行う.envファイルは.gitignoreにて指定されているため、Gitリポジトリにプッシュされません。
なので再度作成します。

root@:/work# cp .env.example .env

.envを作成したらcomposer install、そしてAPP_KEYも発行します。

root@:/work# composer install

root@:/work# php artisan key:generate

プロジェクト内の権限変更

プロジェクト内のファイルに対する権限を変更します。

通常では storage/logs と vendor の権限を変更すればOKみたいです。

ここでもエラーが起き少し苦戦しました。

file_put_contentsエラーでViewが開かない

root@:/work# chmod 777 storage/logs vendor
root@:/work# chmod 777 storage/framework/views
root@:/work# chmod 777 storage/framework/sessions

ここまでやってようやくTOPページが開ました。

http://[設定したElastic IPアドレス]:10080にブラウザからアクセスします。

この様に表示されればOKです。

マイグレーションを実行する

root@:/work# php artisan migrate
root@:/work# php aritsan db:seed

ここまでやればローカルで作成したアプリが動くと思います。

以上で「AWSにEC2上にdockerを使用したlaravelをデプロイ」を終了させていただきます。
ありがとうございました。

前回の記事
AWSにEC2上にdockerを使用したlaravelをデプロイ③

＊＊間違い等ございましたらご指摘お願い致します＊＊

概要

・自分が詰まったポイントと同じポイントで詰まった方向けにAWSにlaravel/dockerをデプロイするまでの過程を書いていきます。

前回の記事
AWSにdockerを使用したlaravelをデプロイ②

EC2インスタンスにSSHでアクセスする

1:EC2ダッシュボード作成したインスタンスに入りの右上の「接続」をクリック

2:インスタンスに接続コード確認
「SSH クライアント」をクリック

3:EC2インスタンスにSSHでアクセス
ターミナルを起動し

chmod 400 test-docker.pem
ssh -i "test-docker.pem" ubuntu@ec2-52-198-43-4.ap-northeast1.compute.amazonaws.com

test-docker.pemの部分はダウンロードし格納したディレクトリを指定して下さい。

Gitのインストール

EC2内への変更にはスーパーユーザーで行わないといけないので「sudo」を打つか

ubuntu@ip:~$ sudo su
root@ip:/home/ubuntu# 

行頭にある「$（ドル）」が一般ユーザーを表し、「#（シャープ）」がrootユーザーを表します。

1:aptの更新

root@ip:/home/ubuntu# apt-get update

2:Gitのインストール
Gitのインストールと初期設定を行います。

#gitインストール
root@ip:/home/ubuntu# apt-get install git

#git初期設定
root@ip:/home/ubuntu# git config --global user.name [任意のユーザー名]
root@ip:/home/ubuntu# git config --global user.email [任意のemailアドレス]

Docker,Docker-composeのインストール

ubuntu用の手順をDocker公式ページに従います。
Docker,Docker-composeのインストールを行います。

root@ip:/home/ubuntu＃　apt-get install \apt-transport-https \ca-certificates \curl \gnupg-agent \software-properties-common

root@ip:/home/ubuntu＃ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

root@ip:/home/ubuntu＃ apt-key fingerprint 0EBFCD88

root@ip:/home/ubuntu＃ add-apt-repository \
                      "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
                      $(lsb_release -cs) \
                      stable"

root@ip:/home/ubuntu＃ apt-get install docker-ce docker-ce-cli containerd.io

#docker-composeのインストール
root@ip:/home/ubuntu# apt install docker-compose

前回の記事
AWSにdockerを使用したlaravelをデプロイ②

続きはこちら

＊＊間違い等ございましたらご指摘お願い致します＊＊

概要

・自分が詰まったポイントと同じポイントで詰まった方向けにAWSにlaravel/dockerをデプロイするまでの過程を書いていきます。

前回の記事
AWSにdockerを使用したlaravelをデプロイ②

EC2インスタンスにSSHでアクセスする

1:EC2ダッシュボード作成したインスタンスに入りの右上の「接続」をクリック

2:インスタンスに接続コード確認
「SSH クライアント」をクリック

3:EC2インスタンスにSSHでアクセス
ターミナルを起動し

chmod 400 test-docker.pem
ssh -i "test-docker.pem" ubuntu@ec2-52-198-43-4.ap-northeast1.compute.amazonaws.com

test-docker.pemの部分はダウンロードし格納したディレクトリを指定して下さい。

Gitのインストール

EC2内への変更にはスーパーユーザーで行わないといけないので「sudo」を打つか

ubuntu@ip:~$ sudo su
root@ip:/home/ubuntu# 

行頭にある「$（ドル）」が一般ユーザーを表し、「#（シャープ）」がrootユーザーを表します。

1:aptの更新

root@ip:/home/ubuntu# apt-get update

2:Gitのインストール
Gitのインストールと初期設定を行います。

#gitインストール
root@ip:/home/ubuntu# apt-get install git

#git初期設定
root@ip:/home/ubuntu# git config --global user.name [任意のユーザー名]
root@ip:/home/ubuntu# git config --global user.email [任意のemailアドレス]

Docker,Docker-composeのインストール

ubuntu用の手順をDocker公式ページに従います。
Docker,Docker-composeのインストールを行います。

root@ip:/home/ubuntu＃　apt-get install \apt-transport-https \ca-certificates \curl \gnupg-agent \software-properties-common

root@ip:/home/ubuntu＃ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

root@ip:/home/ubuntu＃ apt-key fingerprint 0EBFCD88

root@ip:/home/ubuntu＃ add-apt-repository \
                      "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
                      $(lsb_release -cs) \
                      stable"

root@ip:/home/ubuntu＃ apt-get install docker-ce docker-ce-cli containerd.io

#docker-composeのインストール
root@ip:/home/ubuntu# apt install docker-compose

前回の記事
AWSにEC2上にdockerを使用したlaravelをデプロイ②

続きはこちら
AWSにdockerを使用したlaravelをデプロイ④

＊＊間違い等ございましたらご指摘お願い致します＊＊

概要

・自分が詰まったポイントと同じポイントで詰まった方向けにAWSにlaravel/dockerをデプロイするまでの過程を書いていきます。

前回の記事
AWSにdockerを使用したlaravelをデプロイ②

EC2インスタンスにSSHでアクセスする

1:EC2ダッシュボード作成したインスタンスに入りの右上の「接続」をクリック

2:インスタンスに接続コード確認
「SSH クライアント」をクリック

3:EC2インスタンスにSSHでアクセス
ターミナルを起動し

chmod 400 test-docker.pem
ssh -i "test-docker.pem" ubuntu@ec2-52-198-43-4.ap-northeast1.compute.amazonaws.com

test-docker.pemの部分はダウンロードし格納したディレクトリを指定して下さい。

Gitのインストール

EC2内への変更にはスーパーユーザーで行わないといけないので「sudo」を打つか

ubuntu@ip:~$ sudo su
root@ip:/home/ubuntu# 

行頭にある「$（ドル）」が一般ユーザーを表し、「#（シャープ）」がrootユーザーを表します。

1:aptの更新

root@ip:/home/ubuntu# apt-get update

2:Gitのインストール
Gitのインストールと初期設定を行います。

#gitインストール
root@ip:/home/ubuntu# apt-get install git

#git初期設定
root@ip:/home/ubuntu# git config --global user.name [任意のユーザー名]
root@ip:/home/ubuntu# git config --global user.email [任意のemailアドレス]

Docker,Docker-composeのインストール

ubuntu用の手順をDocker公式ページに従います。
Docker,Docker-composeのインストールを行います。

root@ip:/home/ubuntu＃　apt-get install \apt-transport-https \ca-certificates \curl \gnupg-agent \software-properties-common

root@ip:/home/ubuntu＃ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

root@ip:/home/ubuntu＃ apt-key fingerprint 0EBFCD88

root@ip:/home/ubuntu＃ add-apt-repository \
                      "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
                      $(lsb_release -cs) \
                      stable"

root@ip:/home/ubuntu＃ apt-get install docker-ce docker-ce-cli containerd.io

#docker-composeのインストール
root@ip:/home/ubuntu# apt install docker-compose

前回の記事
AWSにEC2上にdockerを使用したlaravelをデプロイ②

続きはこちら
AWSにdockerを使用したlaravelをデプロイ④

＊＊間違い等ございましたらご指摘お願い致します＊＊

デプロイ担当者になって

　某プログラミングスクールの最終課題でデプロイ担当になり、改めて学習したことをまとめています。私自身が難解なプログラミングの言語に惑わされることも多いので、初学者にもわかりやすく（初学者の自分でもわかるように）書いていこうと思います。

デプロイについて

　まずそもそもデプロイとは何かですが、簡単に言うと
『ローカルで作成したアプリケーションを、サーバにアップロードをして、世の中に公開する』
です。
…既にカタカナが多くややこしいですよね(　ﾟдﾟ)

　これを経験者ではない方にも、わかりやすく書くと
『自分のパソコンで作って保存してあるアプリを、インターネット上に送って、みんなが利用できるようにする』
です。
　みなさんが利用しているであろう、Twitterやメルカリ、Youtubeなどもデプロイされて使えるようになっているんですね。

デプロイをするために必要なこと

デプロイの流れとしては以下の３点です。

1.アプリケーションを開発する
2.アプリケーションをデプロイするためのサーバを用意する　←ここからまとめていきます
3.実際にアプリケーションをデプロイする

　デプロイをするにはサーバ（インターネット上でアプリを保存しておく場所）が必要になります。ここにユーザー（使う人）がアクセスして使うわけですね。
　世の中にはこのサーバを提供してくれるサービスが色々とあります。今回は、通販で有名なあのAmazonが提供してくれている『AWS』（Amazon Web Servises)というものを利用する方法を次から書いていきます。

今回のまとめ

①デプロイとは、『自分のパソコンで作って保存してあるアプリを、インターネット上に送って、みんなが利用できるようにする』こと

②デプロイをするためには『サーバ』が必要になる。

③『AWS(Amazon Web Servises)』というAmazonが提供しているサーバがある。

※単語のまとめ
・ローカル（自分のパソコンなどインターネット上でない場所）
・サーバ　（インターネット上でアプリを保存しておく場所）
・アプリケーション（アプリとも言われる。制作したサービス。）
・ユーザー（使う人）

経緯

現在のプロジェクトで静的ファイルをS３にホスティングして運用しているので、勉強がてら記録を残します。

AWS S3とは

基本的にストレージを提供するサービスになっています。
画像、動画、ファイルなど様々なデータを保存するサービスで、
例えば、icloudは写真や書類（メモアプリ、pdfなど）を保存するストレージサービスです。

S3は、他のAWSサービスと連帯して使うことができ、
EC2のスナップショット（バックアップ）の保存先、
ファイルアップロード時をイベントトリガーとして、Lambda関数を呼び出しをしたりと、
一般的なストレージサービスより多くの機能を兼ね備えています。

今回は、静的ホスティング機能について記載していこうと思います。

参照：S3ユースケース

静的ホスティングとは

静的なwebサイトをホスティング（一般公開）すること。

静的なwebサイトとはhtmlファイルをサーバにアップロードしておき、
リクエストに対してそのままそのファイルをレスポンスするサイトのこと。

例えば、PHPやJavaはアプリケーションサーバで動作させることにより、
ログイン情報によって処理を行うことができるためリクエストごとに
異なったレスポンスをするので、動的なwebサイトになります。

S3でホスティングする理由

１番の理由はコストが低いです。
料金は、S3 Standardのストレージクラスですと、
ストレージあたり0.025USD/GB、1000リクエストあたり0.00037USD
とレンタルサーバを借りてLPなどを運用するよりはるかに安いです。
また、 フルマネージドサービスなのでサーバのメンテナンス等は考えなくても良いです

参照：料金 - AWS S3

手順

1.index.htmlを作成

公開するhtmlファイルを準備

index.html

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>S3静的ホスティング</title>
</head>
<body>
  <h1>S3静的ホスティング</h1>
</body>
</html>

2.バケットを作成

AWSにログイン後、Amazon S3サービスに移動バケットを作成するを押下し、バケット名を入力してバケットを作成


3.バケットにindex.htmlをアップロード

作成したバケットに移動しアップロードを押下して、先程のhtmlファイルをアップロード


4.静的ホスティングを有効化

アップロードしたindex.htmlをクリックし、
「プロパティ」タブの「Static website hosting」項目の

「このバケットを使用してウェブサイトをホストする」を選択
インデックスドキュメントに静的ホスティングするindex.htmlを入力して保存


5.index.htmlを公開

バケットに戻り、index.htmlを選択してからアクションボタンを押下し、公開するをクリック



※バケット作成時に「パブリックアクセスをすべてブロック」を選択していた場合、
「公開」ボタンが非活性になっているので、その場合は「アクセス権限」タブの「ブロックパブリックアクセス」項目の
「パブリックアクセスをすべてブロック」のチェックを外す


6.静的ホスティングを確認

「プロパティ」タブの「Static website hosting」項目のエンドポイントからアクセス可能


表示を確認できました！


まとめ

公開するソースコードさえ準備していれば、簡単にホスティングできます。

Route53のサービスを使えば、独自ドメインも使うので近いうちに試してみたいと思います。

自己紹介ページやLPページを公開したい方はぜひお試しください！！

概要

・自分が詰まったポイントと同じポイントで詰まった方向けにAWSにlaravel/dockerをデプロイするまでの過程を書いていきます。

前回の記事
AWSにdockerを使用したlaravelをデプロイ①

Elastic IP取得

1:Elastic IPを開く
EC2ダッシュボードの左側のメニューの「Elastic IP」を選択。
「Elastic IPの割り当て」をクリック。

2:「割り当て」をクリック

3:割り当てられたIPをクリック

4:EC2インスタンスに紐づける
「Elastic IP アドレスの関連付け」をクリック

5:インスタンスを選択
「インスタンス」に先ほど作成したEC2インスタンスを選択する。
「関連付ける」をクリック。

これで作成したインスタンスにElastic IPが紐付けられました。

前回の記事
AWSにEC2上にdockerを使用したlaravelをデプロイ①

続きはこちら
AWSにEC2上にdockerを使用したlaravelをデプロイ③

＊＊間違い等ございましたらご指摘お願い致します＊＊

概要

・自分が詰まったポイントと同じポイントで詰まった方向けにAWSにlaravel/dockerをデプロイするまでの過程を書いていきます。

前回の記事
AWSにdockerを使用したlaravelをデプロイ①

Elastic IP取得

1:Elastic IPを開く
EC2ダッシュボードの左側のメニューの「Elastic IP」を選択。
「Elastic IPの割り当て」をクリック。

2:「割り当て」をクリック

3:割り当てられたIPをクリック

4:EC2インスタンスに紐づける
「Elastic IP アドレスの関連付け」をクリック

5:インスタンスを選択
「インスタンス」に先ほど作成したEC2インスタンスを選択する。
「関連付ける」をクリック。

これで作成したインスタンスにElastic IPが紐付けられました。

前回の記事
AWSにEC2上にdockerを使用したlaravelをデプロイ①

続きはこちら
AWSにEC2上にdockerを使用したlaravelをデプロイ③

＊＊間違い等ございましたらご指摘お願い致します＊＊

概要

・自分が詰まったポイントと同じポイントで詰まった方向けにAWSにlaravel/dockerをデプロイするまでの過程を書いていきます。

前回の記事
AWSにdockerを使用したlaravelをデプロイ①

Elastic IP取得

1:Elastic IPを開く
EC2ダッシュボードの左側のメニューの「Elastic IP」を選択。
「Elastic IPの割り当て」をクリック。

2:「割り当て」をクリック

3:割り当てられたIPをクリック

4:EC2インスタンスに紐づける
「Elastic IP アドレスの関連付け」をクリック

5:インスタンスを選択
「インスタンス」に先ほど作成したEC2インスタンスを選択する。
「関連付ける」をクリック。

これで作成したインスタンスにElastic IPが紐付けられました。

前回の記事
AWSにdockerを使用したlaravelをデプロイ①

続きはこちら
AWSにdockerを使用したlaravelをデプロイ③

＊＊間違い等ございましたらご指摘お願い致します＊＊

概要

・自分が詰まったポイントと同じポイントで詰まった方向けにAWSにlaravel/dockerをデプロイするまでの過程を書いていきます。

---

前提条件

・Mac基準になります。
・gitにlaravelアプリがpushされている事。
・dockerがインストールされている事。
・AWSにログイン出来る事。

---

構築環境

・php7.4
・mysql8.0
・laravel6

dockerの構築は
@ucan-labさんの記事
【初心者向け】20分でLaravel開発環境を爆速構築するDockerハンズオン
を参考に作成しました。

---

変更点

version: "3.3"　←変更
services:
  app:
    build: ./infra/php
    volumes:
      - ./backend:/work

  web:
    image: nginx:1.18-alpine
    ports:
      - 10080:80
    volumes:
      - ./backend:/work
      - ./infra/nginx/default.conf:/etc/nginx/conf.d/default.conf
    working_dir: /work

---

EC2インスタンス作成

画面右上のリージョンは東京に指定して下さい。
画面左上のサービスを開きEC2を選択。
探せない場合はすべてのサーピスから「EC2」と打ち込んで検索して下さい。
EC2をクリックしアクセス。

1:Webサーバーの作成
インスタンスを起動をクリックし、選択画面が出たらそこもインスタンスの起動をクリック。

２:AMIを選択
AMIは「ubuntu 18.04」を選択。

3:インスタンスタイプの選択
新規登録から1年間無料の利用枠「t2.micro」を選択。

4:インスタンス詳細
標準のまま進みます。

5:ストレージ追加
標準のまま進みます。

6:タグの追加
タグを追加し値を任意の名前を付けます。
今回は「awstest」という名前を付けました。
1つ作ったら次へ。

7:セキュリティーグループ設定
任意のセキュリティーグループ名、説明を設定する。
今回は「test-docker」という名前を付けました。
ルールの追加を行い「HTTP」「HTTPS」「カスタム　TCP　ルール」を追加。
カスタムTCPのみ　ポート範囲を指定。
今回は「10080」を設定します。
ソースには「カスタム」「0.0.0.0/0, ::/0」を設定。
全て設定し終わってら次へ。

8:インスタンス作成
起動ボタンをクリック。

キーペアの作成

インスタンスの「起動」ボタンをクリックすると、キーペアの作成画面が表示されます。

初めてEC2インスタンスを作成する方は
新しいキーペアの作成を選択し、任意の名前をキーペア名につけます。
キーペアのダウンロードを必ず行って下さい。
そしてインスタンス作成をクリック。

作成したインスタンスの確認

EC2の画面に戻ってみると作成したインスタンスがある事が確認できます。
Nameのところにタグの項目で付けた名前があります。
「実行中」「2/2のチェックに合格しました」となったら完了です。

続き

続きはこちら
AWSにEC2上でdockerを使用したlaravelをデプロイ②

＊＊間違い等ございましたらご指摘お願い致します＊＊

概要

・自分が詰まったポイントと同じポイントで詰まった方向けにAWSにlaravel/dockerをデプロイするまでの過程を書いていきます。

---

前提条件

・Mac基準になります。
・gitにlaravelアプリがpushされている事。
・dockerがインストールされている事。
・AWSにログイン出来る事。

---

構築環境

・php7.4
・mysql8.0
・laravel6

dockerの構築は
@ucan-labさんの記事
【初心者向け】20分でLaravel開発環境を爆速構築するDockerハンズオン
を参考に作成しました。

---

変更点

version: "3.3"　←変更
services:
  app:
    build: ./infra/php
    volumes:
      - ./backend:/work

  web:
    image: nginx:1.18-alpine
    ports:
      - 10080:80
    volumes:
      - ./backend:/work
      - ./infra/nginx/default.conf:/etc/nginx/conf.d/default.conf
    working_dir: /work

---

EC2インスタンス作成

画面右上のリージョンは東京に指定して下さい。
画面左上のサービスを開きEC2を選択。
探せない場合はすべてのサーピスから「EC2」と打ち込んで検索して下さい。
EC2をクリックしアクセス。

1:Webサーバーの作成
インスタンスを起動をクリックし、選択画面が出たらそこもインスタンスの起動をクリック。

２:AMIを選択
AMIは「ubuntu 18.04」を選択。

3:インスタンスタイプの選択
新規登録から1年間無料の利用枠「t2.micro」を選択。

4:インスタンス詳細
標準のまま進みます。

5:ストレージ追加
標準のまま進みます。

6:タグの追加
タグを追加し値を任意の名前を付けます。
今回は「awstest」という名前を付けました。
1つ作ったら次へ。

7:セキュリティーグループ設定
任意のセキュリティーグループ名、説明を設定する。
今回は「test-docker」という名前を付けました。
ルールの追加を行い「HTTP」「HTTPS」「カスタム　TCP　ルール」を追加。
カスタムTCPのみ　ポート範囲を指定。
今回は「10080」を設定します。
ソースには「カスタム」「0.0.0.0/0, ::/0」を設定。
全て設定し終わってら次へ。

8:インスタンス作成
起動ボタンをクリック。

キーペアの作成

インスタンスの「起動」ボタンをクリックすると、キーペアの作成画面が表示されます。

初めてEC2インスタンスを作成する方は
新しいキーペアの作成を選択し、任意の名前をキーペア名につけます。
キーペアのダウンロードを必ず行って下さい。
そしてインスタンス作成をクリック。

作成したインスタンスの確認

EC2の画面に戻ってみると作成したインスタンスがある事が確認できます。
Nameのところにタグの項目で付けた名前があります。
「実行中」「2/2のチェックに合格しました」となったら完了です。

続き

続きはこちら
AWSにEC2上でdockerを使用したlaravelをデプロイ②

＊＊間違い等ございましたらご指摘お願い致します＊＊

概要

・自分が詰まったポイントと同じポイントで詰まった方向けにAWSにlaravel/dockerをデプロイするまでの過程を書いていきます。

---

前提条件

・Mac基準になります。
・gitにlaravelアプリがpushされている事。
・dockerがインストールされている事。
・AWSにログイン出来る事。

---

構築環境

・php7.4
・mysql8.0
・laravel6

dockerの構築は
@ucan-labさんの記事
【初心者向け】20分でLaravel開発環境を爆速構築するDockerハンズオン
を参考に作成しました。

---

変更点

version: "3.3"　←変更
services:
  app:
    build: ./infra/php
    volumes:
      - ./backend:/work

  web:
    image: nginx:1.18-alpine
    ports:
      - 10080:80
    volumes:
      - ./backend:/work
      - ./infra/nginx/default.conf:/etc/nginx/conf.d/default.conf
    working_dir: /work

---

EC2インスタンス作成

画面右上のリージョンは東京に指定して下さい。
画面左上のサービスを開きEC2を選択。
探せない場合はすべてのサーピスから「EC2」と打ち込んで検索して下さい。
EC2をクリックしアクセス。

1:Webサーバーの作成
インスタンスを起動をクリックし、選択画面が出たらそこもインスタンスの起動をクリック。

２:AMIを選択
AMIは「ubuntu 18.04」を選択。

3:インスタンスタイプの選択
新規登録から1年間無料の利用枠「t2.micro」を選択。

4:インスタンス詳細
標準のまま進みます。

5:ストレージ追加
標準のまま進みます。

6:タグの追加
タグを追加し値を任意の名前を付けます。
今回は「awstest」という名前を付けました。
1つ作ったら次へ。

7:セキュリティーグループ設定
任意のセキュリティーグループ名、説明を設定する。
今回は「test-docker」という名前を付けました。
ルールの追加を行い「HTTP」「HTTPS」「カスタム　TCP　ルール」を追加。
カスタムTCPのみ　ポート範囲を指定。
今回は「10080」を設定します。
ソースには「カスタム」「0.0.0.0/0, ::/0」を設定。
全て設定し終わってら次へ。

8:インスタンス作成
起動ボタンをクリック。

キーペアの作成

インスタンスの「起動」ボタンをクリックすると、キーペアの作成画面が表示されます。

初めてEC2インスタンスを作成する方は
新しいキーペアの作成を選択し、任意の名前をキーペア名につけます。
キーペアのダウンロードを必ず行って下さい。
そしてインスタンス作成をクリック。

作成したインスタンスの確認

EC2の画面に戻ってみると作成したインスタンスがある事が確認できます。
Nameのところにタグの項目で付けた名前があります。
「実行中」「2/2のチェックに合格しました」となったら完了です。

続き

続きはこちら
AWSにdockerを使用したlaravelをデプロイ②

＊＊間違い等ございましたらご指摘お願い致します＊＊