20210110のAWSに関する記事は19件です。

投稿日：2021-01-10T21:40:57+09:00

EC2でartisanが作動しない時にやること

背景

Mac環境でLaravelプロジェクトをAWSのEC2にデプロイしようとしたところ、php artisan key:generateがPHP Fatal errarで返ってきてしまいました。
しかし何日かの奮闘の末、解決することが出来たので、同じ悩みを持つ方の手助けに少しでもなればと思いその解決方法を共有させていただきます。

結論：バージョンとcomposer.json

このエラーは
1. composer.jsonの中身がおかしかったこと
2. ローカルのものとEC2上のものでバージョンが違っていたこと
の2点が原因でした。したがってまずcomposer.jsonの中身を書き換えるところから説明していきます。

composer.jsonの中身を書き換える

重要なcomposerのファイルは2種類あります。ここまで来た方なら２つとも既に存在しているファイルです。
composer.json
- composer installを実行する際にはこのjsonファイルの定義を元にパッケージのダウンロードを行う
- composer updateでjsonの定義を元に各バージョンのライブラリををアップデートする。
composer.lock
- composer installでlockに書き出されて各バージョンのライブラリをダウンロードする。

引用　https://qiita.com/a-nishimura/items/8c71085183e0b8a53f6a

したがってcomposer　installにおいて、composer.jsonの定義がとても重要になります。しかし私の場合、このjsonファイルが2行しか書かれていませんでした。
確認及び書き換えはvim compose.jsonで行うことが出来ます。内容を確認した後、jsonファイルを以下の内容に書き換えましょう。
{
  "name": "laravel/laravel",
"type": "project",
"description": "The Laravel Framework.",
"keywords": [
    "framework",
    "laravel"
],
"license": "MIT",
"require": {
    "php": "^7.2.5|^8.0",
    "fideloper/proxy": "^4.4",
    "laravel/framework": "^6.20",
    "laravel/tinker": "^2.5"
},
"require-dev": {
    "barryvdh/laravel-debugbar": "^3.3",
    "facade/ignition": "^1.16.4",
    "fakerphp/faker": "^1.9.1",
    "laravel/ui": "^1.2",
    "mockery/mockery": "^1.0",
    "nunomaduro/collision": "^3.0",
    "phpunit/phpunit": "^8.5.8|^9.3.3"
},
"config": {
    "optimize-autoloader": true,
    "preferred-install": "dist",
    "sort-packages": true
},
"extra": {
    "laravel": {
        "dont-discover": []
    }
},
"autoload": {
    "psr-4": {
        "App\\": "app/"
    },
    "classmap": [
        "database/seeds",
        "database/factories"
    ]
},
"autoload-dev": {
    "psr-4": {
        "Tests\\": "tests/"
    }
},
"minimum-stability": "dev",
"prefer-stable": true,
"scripts": {
    "post-autoload-dump": [
        "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
        "@php artisan package:discover --ansi"
    ],
    "post-root-package-install": [
        "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
    ],
    "post-create-project-cmd": [
        "@php artisan key:generate --ansi"
    ]
}
この段階ではまだcomposerのインストールは行いません。
次にバージョン合わせです。

バージョンを合わせる

私の場合、ローカルがPHP7.3、EC2がPHP7.2でした。ということはEC2上でPHPのバージョンを7.2から7.3へと上げなければなりません。以下にそのやり方を記述していきます。
まずPHPのバージョンを確認していきましょう。
php -v
次にバージョンを7.2から7.3へ上げていきます。
sudo amazon-linux-extras disable php7.2
sudo amazon-linux-extras disable lamp-mariadb10.2-php7.2
sudo amazon-linux-extras enable php7.3
sudo yum install php-cli php-pdo php-fpm php-json php-mysqlnd
sudo yum install php-mbstring
sudo yum install php-dom
参考：https://forums.aws.amazon.com/thread.jspa?messageID=908568

composerをインストールする

これで最後です。
composer install

最後に

ここまでお疲れ様でした。最後に、私がこの方法に行き着くまでに試したコマンドを以下に載せようと思います。あとdisableにしているlamp-maraiadb10.2のことを忘れないでくださいね。
composer update composer update —no-scripts composer dump-autoload
これらが上手くいかなかったのは、前述の通り大元のcomposer.jsonを書き替えてなかったからだと思います。

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-10T21:40:57+09:00

EC2にLaravelプロジェクトをデプロイする際、artisanが実行できない時にやること

背景

Mac環境でLaravelプロジェクトをAWSのEC2にデプロイしようとしたところ、php artisan key:generateがPHP Fatal errarで返ってきてしまいました。
しかし何日かの奮闘の末、解決することが出来たので、同じ悩みを持つ方の手助けに少しでもなればと思いその解決方法を共有させていただきます。

結論：バージョンとcomposer.json

このエラーは
1. composer.jsonの中身がおかしかったこと
2. ローカルのものとEC2上のものでバージョンが違っていたこと
の2点が原因でした。したがってまずcomposer.jsonの中身を書き換えるところから説明していきます。

composer.jsonの中身を書き換える

重要なcomposerのファイルは2種類あります。ここまで来た方なら２つとも既に存在しているファイルです。
composer.json
- composer installを実行する際にはこのjsonファイルの定義を元にパッケージのダウンロードを行う
- composer updateでjsonの定義を元に各バージョンのライブラリををアップデートする。
composer.lock
- composer installでlockに書き出されて各バージョンのライブラリをダウンロードする。

引用　https://qiita.com/a-nishimura/items/8c71085183e0b8a53f6a

したがってcomposer　installにおいて、composer.jsonの定義がとても重要になります。しかし私の場合、このjsonファイルが2行しか書かれていませんでした。
確認及び書き換えはvim compose.jsonで行うことが出来ます。内容を確認した後、jsonファイルを以下の内容に書き換えましょう。
{
  "name": "laravel/laravel",
"type": "project",
"description": "The Laravel Framework.",
"keywords": [
    "framework",
    "laravel"
],
"license": "MIT",
"require": {
    "php": "^7.2.5|^8.0",
    "fideloper/proxy": "^4.4",
    "laravel/framework": "^6.20",
    "laravel/tinker": "^2.5"
},
"require-dev": {
    "barryvdh/laravel-debugbar": "^3.3",
    "facade/ignition": "^1.16.4",
    "fakerphp/faker": "^1.9.1",
    "laravel/ui": "^1.2",
    "mockery/mockery": "^1.0",
    "nunomaduro/collision": "^3.0",
    "phpunit/phpunit": "^8.5.8|^9.3.3"
},
"config": {
    "optimize-autoloader": true,
    "preferred-install": "dist",
    "sort-packages": true
},
"extra": {
    "laravel": {
        "dont-discover": []
    }
},
"autoload": {
    "psr-4": {
        "App\\": "app/"
    },
    "classmap": [
        "database/seeds",
        "database/factories"
    ]
},
"autoload-dev": {
    "psr-4": {
        "Tests\\": "tests/"
    }
},
"minimum-stability": "dev",
"prefer-stable": true,
"scripts": {
    "post-autoload-dump": [
        "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
        "@php artisan package:discover --ansi"
    ],
    "post-root-package-install": [
        "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
    ],
    "post-create-project-cmd": [
        "@php artisan key:generate --ansi"
    ]
}
この段階ではまだcomposerのインストールは行いません。
次にバージョン合わせです。

バージョンを合わせる

私の場合、ローカルがPHP7.3、EC2がPHP7.2でした。ということはEC2上でPHPのバージョンを7.2から7.3へと上げなければなりません。以下にそのやり方を記述していきます。
まずPHPのバージョンを確認していきましょう。
php -v
次にバージョンを7.2から7.3へ上げていきます。
sudo amazon-linux-extras disable php7.2
sudo amazon-linux-extras disable lamp-mariadb10.2-php7.2
sudo amazon-linux-extras enable php7.3
sudo yum install php-cli php-pdo php-fpm php-json php-mysqlnd
sudo yum install php-mbstring
sudo yum install php-dom
参考：https://forums.aws.amazon.com/thread.jspa?messageID=908568

composerをインストールする

これで最後です。
composer install

最後に

ここまでお疲れ様でした。最後に、私がこの方法に行き着くまでに試したコマンドを以下に載せようと思います。あとdisableにしているlamp-maraiadb10.2のことを忘れないでくださいね。
composer update composer update —no-scripts composer dump-autoload
これらが上手くいかなかったのは、前述の通り大元のcomposer.jsonを書き替えてなかったからだと思います。

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-10T21:40:57+09:00

EC2にLaravelプロジェクトをデプロイしていく中で、artisanが実行できなくなった時にやること

背景

Mac環境でLaravelプロジェクトをAWSのEC2にデプロイしようとしたところ、php artisan key:generateがPHP Fatal errarで返ってきてしまいました。
しかし何日かの奮闘の末、解決することが出来たので、同じ悩みを持つ方の手助けに少しでもなればと思いその解決方法を共有させていただきます。

結論：バージョンとcomposer.json

このエラーは
1. composer.jsonの中身がおかしかったこと
2. ローカルのものとEC2上のものでバージョンが違っていたこと
の2点が原因でした。したがってまずcomposer.jsonの中身を書き換えるところから説明していきます。

composer.jsonの中身を書き換える

重要なcomposerのファイルは2種類あります。ここまで来た方なら２つとも既に存在しているファイルです。
composer.json
- composer installを実行する際にはこのjsonファイルの定義を元にパッケージのダウンロードを行う
- composer updateでjsonの定義を元に各バージョンのライブラリををアップデートする。
composer.lock
- composer installでlockに書き出されて各バージョンのライブラリをダウンロードする。

引用　https://qiita.com/a-nishimura/items/8c71085183e0b8a53f6a

したがってcomposer　installにおいて、composer.jsonの定義がとても重要になります。しかし私の場合、このjsonファイルが2行しか書かれていませんでした。
確認及び書き換えはvim compose.jsonで行うことが出来ます。内容を確認した後、jsonファイルを以下の内容に書き換えましょう。
{
  "name": "laravel/laravel",
"type": "project",
"description": "The Laravel Framework.",
"keywords": [
    "framework",
    "laravel"
],
"license": "MIT",
"require": {
    "php": "^7.2.5|^8.0",
    "fideloper/proxy": "^4.4",
    "laravel/framework": "^6.20",
    "laravel/tinker": "^2.5"
},
"require-dev": {
    "barryvdh/laravel-debugbar": "^3.3",
    "facade/ignition": "^1.16.4",
    "fakerphp/faker": "^1.9.1",
    "laravel/ui": "^1.2",
    "mockery/mockery": "^1.0",
    "nunomaduro/collision": "^3.0",
    "phpunit/phpunit": "^8.5.8|^9.3.3"
},
"config": {
    "optimize-autoloader": true,
    "preferred-install": "dist",
    "sort-packages": true
},
"extra": {
    "laravel": {
        "dont-discover": []
    }
},
"autoload": {
    "psr-4": {
        "App\\": "app/"
    },
    "classmap": [
        "database/seeds",
        "database/factories"
    ]
},
"autoload-dev": {
    "psr-4": {
        "Tests\\": "tests/"
    }
},
"minimum-stability": "dev",
"prefer-stable": true,
"scripts": {
    "post-autoload-dump": [
        "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
        "@php artisan package:discover --ansi"
    ],
    "post-root-package-install": [
        "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
    ],
    "post-create-project-cmd": [
        "@php artisan key:generate --ansi"
    ]
}
この段階ではまだcomposerのインストールは行いません。
次にバージョン合わせです。

バージョンを合わせる

私の場合、ローカルがPHP7.3、EC2がPHP7.2でした。ということはEC2上でPHPのバージョンを7.2から7.3へと上げなければなりません。以下にそのやり方を記述していきます。
まずPHPのバージョンを確認していきましょう。
php -v
次にバージョンを7.2から7.3へ上げていきます。
sudo amazon-linux-extras disable php7.2
sudo amazon-linux-extras disable lamp-mariadb10.2-php7.2
sudo amazon-linux-extras enable php7.3
sudo yum install php-cli php-pdo php-fpm php-json php-mysqlnd
sudo yum install php-mbstring
sudo yum install php-dom
参考：https://forums.aws.amazon.com/thread.jspa?messageID=908568

composerをインストールする

これで最後です。
composer install

最後に

ここまでお疲れ様でした。最後に、私がこの方法に行き着くまでに試したコマンドを以下に載せようと思います。あとdisableにしているlamp-maraiadb10.2のことを忘れないでくださいね。
composer update composer update —no-scripts composer dump-autoload
これらが上手くいかなかったのは、前述の通り大元のcomposer.jsonを書き替えてなかったからだと思います。

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-10T21:18:37+09:00

WordPressの開発環境をDocker(Local)とAWS(Production)で構築手順

表題の通り、WordPressの開発環境をDockerとAWSで構築したのでその手順についてまとめます。

まとめる内容は以下になります。

WordPressのLocal環境をDockerで構築

Webpackでscssとjsをcompileしてthemesディレクトリにoutput

scssとｊｓはassetsディレクトリで作業する

開発ファイルはGitで管理する

WordPressのProduction環境をAWSで構築

Public Subnet、Private SubnetでそれぞれEC2 InstanceにWordPressとMySQLをinstall

EC2 InstanceにGitを配置して開発ファイルをPullするとLocal作業が反映される

Local環境

WordPress の Local 環境を Docker で構築

Webpack で js と scss ファイルを compile して themes に output

Docker image の version
image: mysql:8.0.22
image: wordpress:latest
docker-compose.yaml
version: '3'

services:
  db:
    image: mysql:8.0.22
    volumes:
      - db_data:/var/lib/mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: password
      MYSQL_DATABASE: wordpress
      MYSQL_USER: admin
      MYSQL_PASSWORD: password
    networks:
      - wpsite
  phpmyadmin:
    depends_on:
      - db
    image: phpmyadmin/phpmyadmin
    restart: always
    ports:
      - '8080:80'
    environment:
      PMA_HOST: db
      MYSQL_ROOT_PASSWORD: password
    networks:
      - wpsite
  wordpress:
    depends_on:
      - db
    image: wordpress:latest
    ports:
      - '8000:80'
    restart: always
    volumes: ['./../src:/var/www/html']
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: admin
      WORDPRESS_DB_PASSWORD: password
    networks:
      - wpsite
networks:
  wpsite:
volumes:
  db_data:
開発作業

scss と js の作業はassetsディレクトリ内で行う(assets/css/、assets/js/)

assetsディレクトリ内で Webpack 起動

scss と js を変更すると自動で compile されて themes に output

js はruntime.jsとvendors.jsとindex.jsで分割される

jQueryをinstall
webpack.config.js
const webpack = require('webpack');
const path = require('path');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');

const themeName = 'original';

module.exports = {
  mode: 'production',
  entry: {
    index: ['./js/index.js', './css/style.scss'],
  },
  output: {
    filename: 'js/[name].js',
    path: path.resolve(__dirname, `../src/wp-content/themes/${themeName}`),
    publicPath: '/',
  },
  optimization: {
    runtimeChunk: 'single',
    splitChunks: {
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
          chunks: 'all',
        },
      },
    },
  },
  module: {
    rules: [
      {
        test: /\.js?$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-env'],
          },
        },
      },
      {
        test: /\.scss$/,
        use: [
          {
            loader: MiniCssExtractPlugin.loader,
          },
          'css-loader',
          'sass-loader',
        ],
      },
    ],
  },
  plugins: [
    new MiniCssExtractPlugin({
      filename: 'css/style.css',
    }),
    new webpack.ProvidePlugin({
      $: 'jquery',
      jQuery: 'jquery',
    }),
  ],
};
webpack 起動コマンド
$ cd assets
$ npm start
Local 環境

/dockerディレクトリに移動して docker(docker-compose up -d) 起動

http://localhost:8000/が wordpress の local URL

http://localhost:8080/が phpmyadmin の local URL

tree

assets/jsのファイルをsrc/wp-content/themes/original/jsに webpack で compile
├── assets
│   ├── css
│   │   └── style.scss
│   ├── js
│   │   └── index.js
│   ├── node_modules
│   ├── package-lock.json
│   ├── package.json
│   └── webpack.config.js
├── docker
│   └── docker-compose.yaml
└── src
    ├── index.php
    ├── wp-admin
    ├── wp-config-sample.php
    ├── wp-content
        ├── index.php
        ├── languages
        ├── plugins
        ├── themes
            ├── index.php
            ├── original
                └── css
                    └── style.css
                └── js
                    └── index.js
                    └── runtime.js
                    └── vendors.js
gitignore
src/.htaccess
src/wp-config.php
src/wp-content/uploads/
src/wp-content/upgrade/
Docker コマンド

コンテナ表示
$ docker ps
image 一覧
$ docker images
コンテナ起動

-dを実行すると、コンテナはバックグラウンドで起動し、そのまま実行し続けます。
$ docker-compose up -d
コンテナ停止
$ docker-compose down
本番環境

AWS で構築

Public Subnet

Apatch を install して Web サーバーとする

Internet Gatewayで外部からの通信を許可

Private Subnet

NAT Gatewayを介して外部からの通信を可能するが、サブネットからは通信を不可

MySQL を install して DB サーバーとする

構成図

SSH でログイン
$ ssh -i {秘密鍵}.pem ec2-user@{IPv4パブリックIP}
Web サーバーを踏み台として DB サーバーに SSH ログインして MySQL をinstall

DB サーバーはインバウンドでInternetと接続してない

インバウンドで SSH での接続を許可しているので Web サーバーを踏み台に SSH ログインする

SSH ログインするには pem key を Web サーバーに配置する

NAT GatewayでPublic Subnetを通してInternetに接続できるようにする

DB サーバーにログインして MySQL をinstallする

pem key を scp コマンドで Web サーバーにコピーして配置
$ scp -i {秘密鍵}.pem {秘密鍵}.pem ec2-user@{IPv4パブリックIP}:~/
DB サーバーに SSH ログイン
$ ssh -i {秘密鍵}.pem ec2-user@{プライベート IPv4 アドレス}
参考サイト

Amazon Linux2 の MariaDB を MySQL に差し替えでつまずいた点

AWS EC2 AmazonLinux2 MySQL root ユーザの初期パスワードの確認方法

MySQL コマンド

MySQL 起動
$ sudo service mysqld start
MySQL が起動しているか確認
$ systemctl status mysqld.service
MySQL にログイン
$ mysql -u root -p
初期設定パスワードを変更
mysql> set password for 'root'@'localhost' = '********';
データベースwordpressを作成
CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
ユーザー ID と PW を設定
mysql> create user '{ユーザーID}'@'%' identified by '{password}';
ユーザーに権限を付与
※権限を付与しないと Wordpress のデータベース接続ができない
mysql> grant create on *.* to {ユーザーID};
ユーザーが作成されたか確認
mysql> select user, host from mysql.user;
参考サイト

mysql で root の password を変更しようとして Syntax エラー吐かれた

MySQL8.0 では GRANT でユーザ登録ができなかった話

WordPress をインストール

Apache が install されている EC2 インスタンスに SSH ログイン

amazon-linux-extras リポジトリから php を Web サーバーに install

php7.4 に対応したライブラリの install

WordPress を install

WordPress 本体を Apache から見える場所に配置(/var/www/html/)

ファイルの所有者を apache に変更

パブリック IPv4 アドレスで WordPress 管理画面が表示される

amazon-linux-extras リポジトリのソフトウェア一覧を表示
$ amazon-linux-extras
php7.4 を install
$ sudo amazon-linux-extras install -y php7.4
php7.4 に対応したライブラリの install
$ sudo yum install -y php php-mbstring
WordPress を install
$ wget https://wordpress.org/latest.tar.gz
install したフォルダをを解凍
$ tar -xzf latest.tar.gz
WordPress 本体を Apache から見える場所に配置(/var/www/html/)
$ cd wordpress/
$ sudo cp -r * /var/www/html/
ファイルの所有者を apache に変更
$ sudo chown apache:apache /var/www/html/ -R
参考サイト

チュートリアル: Amazon Linux による WordPress ブログのホスティング

WordPress とデータベース接続のエラーでハマった点

WordPress を install して管理画面でデータベース接続ができずにハマりました。その対応策としては mysql のユーザー ID に権限を付与してなかったからです。

データベースを使用する権限を付与 part1
エラー文
「ユーザー xxx にはデータベース wordpress を使用できる権限がありますか ?」
ユーザーに権限を付与
※権限を付与しないと Wordpress のデータベース接続ができない
mysql> grant create on *.* to {ユーザーID};
データベースを使用する権限を付与 part2
エラー文
WordPress データベースエラー: [SELECT command denied to user '{ユーザーID}'@'{host}' for table 'wp_options']
作成したデータベースを書き込めるようにユーザーに権限を付与
mysql> grant all on wordpress.\* to '{ユーザーID}'@'{host}';
Web サーバーから DB サーバーに通信疎通できない場合
エラー文
Authentication plugin 'caching_sha2_password' cannot be loaded: /usr/lib64/mysql/plugin/caching_sha2_password.so: cannot open shared object file: No such file or directory
plugin を「caching_sha2_password 」から「mysql_native_password」に変更する
mysql> ALTER USER '{ユーザーID}'@'{host}' IDENTIFIED WITH mysql_native_password BY '{password}';
参考サイト

Sequel Pro で MySQL にログインできない

Medial Diagnosis And Treatment

EC2 に git をインストール

EC2 Instanceに SSH ログイン
$ sudo yum -y update
$ sudo yum install git
GitHub のアカウント接続する(下記参考サイトを参照)

Apatch の DocumentRoot を変更する

デフォルトでは/var/www/htmlのファイルがページに表示されるので、それを git で pull したファイルを読むように変更する(下記参考サイトを参照)

/var/www/htmlのファイルを/var/tmp/{リポジトリ名/src}にコピーする
$ cp -pR /var/www/html/* /var/lib/{リポジトリ名/src}/
設定ファイル/etc/httpd/conf/httpd.confの書き換え
DocumentRoot "/var/tmp/{リポジトリ名/src}"

<Directory "/var/tmp/{リポジトリ名/src}">
Apatch を再起動
$ sudo systemctl restart httpd
作成したフォルダ・ファイルの所有者を apache に変更
$ sudo chown apache:apache /var/tmp/{リポジトリ名/src}
権限を付与
$ sudo chmod 600 /var/tmp/{リポジトリ名/src}
参考サイト

GitHub ユーザアカウントと GitHub リポジトリ作成 + AWS EC2 から GitHub リポジトリへ push する手順例

【Apache】DocumentRoot を変更しよう

AWS（EC2）で Redmine と Git、Jenkins を使った WordPress 開発環境の構築と公開を行う

以上となります。
これでPublic SubnetのEC2 Instanceの/var/tmp/{リポジトリ名/でgit pullすると開発コードが反映されるかと思います。

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-10T21:18:37+09:00

WordPressの開発環境をDocker(Local)とAWS(Production)で構築

表題の通り、WordPressの開発環境をDockerとAWSで構築したのでその手順についてまとめます。

まとめる内容は以下になります。

WordPressのLocal環境をDockerで構築

Webpackでscssとjsをcompileしてthemesディレクトリにoutput

scssとｊｓはassetsディレクトリで作業する

開発ファイルはGitで管理する

WordPressのProduction環境をAWSで構築

Public Subnet、Private SubnetでそれぞれEC2 InstanceにWordPressとMySQLをinstall

EC2 InstanceにGitを配置して開発ファイルをPullするとLocal作業が反映される

Local環境

WordPress の Local 環境を Docker で構築

Webpack で js と scss ファイルを compile して themes に output

Docker image の version
image: mysql:8.0.22
image: wordpress:latest
docker-compose.yaml
version: '3'

services:
  db:
    image: mysql:8.0.22
    volumes:
      - db_data:/var/lib/mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: password
      MYSQL_DATABASE: wordpress
      MYSQL_USER: admin
      MYSQL_PASSWORD: password
    networks:
      - wpsite
  phpmyadmin:
    depends_on:
      - db
    image: phpmyadmin/phpmyadmin
    restart: always
    ports:
      - '8080:80'
    environment:
      PMA_HOST: db
      MYSQL_ROOT_PASSWORD: password
    networks:
      - wpsite
  wordpress:
    depends_on:
      - db
    image: wordpress:latest
    ports:
      - '8000:80'
    restart: always
    volumes: ['./../src:/var/www/html']
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: admin
      WORDPRESS_DB_PASSWORD: password
    networks:
      - wpsite
networks:
  wpsite:
volumes:
  db_data:
開発作業

scss と js の作業はassetsディレクトリ内で行う(assets/css/、assets/js/)

assetsディレクトリ内で Webpack 起動

scss と js を変更すると自動で compile されて themes に output

js はruntime.jsとvendors.jsとindex.jsで分割される

jQueryをinstall
webpack.config.js
const webpack = require('webpack');
const path = require('path');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');

const themeName = 'original';

module.exports = {
  mode: 'production',
  entry: {
    index: ['./js/index.js', './css/style.scss'],
  },
  output: {
    filename: 'js/[name].js',
    path: path.resolve(__dirname, `../src/wp-content/themes/${themeName}`),
    publicPath: '/',
  },
  optimization: {
    runtimeChunk: 'single',
    splitChunks: {
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
          chunks: 'all',
        },
      },
    },
  },
  module: {
    rules: [
      {
        test: /\.js?$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-env'],
          },
        },
      },
      {
        test: /\.scss$/,
        use: [
          {
            loader: MiniCssExtractPlugin.loader,
          },
          'css-loader',
          'sass-loader',
        ],
      },
    ],
  },
  plugins: [
    new MiniCssExtractPlugin({
      filename: 'css/style.css',
    }),
    new webpack.ProvidePlugin({
      $: 'jquery',
      jQuery: 'jquery',
    }),
  ],
};
webpack 起動コマンド
$ cd assets
$ npm start
Local 環境

/dockerディレクトリに移動して docker(docker-compose up -d) 起動

http://localhost:8000/が wordpress の local URL

http://localhost:8080/が phpmyadmin の local URL

tree

assets/jsのファイルをsrc/wp-content/themes/original/jsに webpack で compile
├── assets
│   ├── css
│   │   └── style.scss
│   ├── js
│   │   └── index.js
│   ├── node_modules
│   ├── package-lock.json
│   ├── package.json
│   └── webpack.config.js
├── docker
│   └── docker-compose.yaml
└── src
    ├── index.php
    ├── wp-admin
    ├── wp-config-sample.php
    ├── wp-content
        ├── index.php
        ├── languages
        ├── plugins
        ├── themes
            ├── index.php
            ├── original
                └── css
                    └── style.css
                └── js
                    └── index.js
                    └── runtime.js
                    └── vendors.js
gitignore
src/.htaccess
src/wp-config.php
src/wp-content/uploads/
src/wp-content/upgrade/
Docker コマンド

コンテナ表示
$ docker ps
image 一覧
$ docker images
コンテナ起動

-dを実行すると、コンテナはバックグラウンドで起動し、そのまま実行し続けます。
$ docker-compose up -d
コンテナ停止
$ docker-compose down
本番環境

AWS で構築

Public Subnet

Apatch を install して Web サーバーとする

Internet Gatewayで外部からの通信を許可

Private Subnet

NAT Gatewayを介して外部からの通信を可能するが、サブネットからは通信を不可

MySQL を install して DB サーバーとする

構成図

SSH でログイン
$ ssh -i {秘密鍵}.pem ec2-user@{IPv4パブリックIP}
Web サーバーを踏み台として DB サーバーに SSH ログインして MySQL をinstall

DB サーバーはインバウンドでInternetと接続してない

インバウンドで SSH での接続を許可しているので Web サーバーを踏み台に SSH ログインする

SSH ログインするには pem key を Web サーバーに配置する

NAT GatewayでPublic Subnetを通してInternetに接続できるようにする

DB サーバーにログインして MySQL をinstallする

pem key を scp コマンドで Web サーバーにコピーして配置
$ scp -i {秘密鍵}.pem {秘密鍵}.pem ec2-user@{IPv4パブリックIP}:~/
DB サーバーに SSH ログイン
$ ssh -i {秘密鍵}.pem ec2-user@{プライベート IPv4 アドレス}
参考サイト

Amazon Linux2 の MariaDB を MySQL に差し替えでつまずいた点

AWS EC2 AmazonLinux2 MySQL root ユーザの初期パスワードの確認方法

MySQL コマンド

MySQL 起動
$ sudo service mysqld start
MySQL が起動しているか確認
$ systemctl status mysqld.service
MySQL にログイン
$ mysql -u root -p
初期設定パスワードを変更
mysql> set password for 'root'@'localhost' = '********';
データベースwordpressを作成
CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
ユーザー ID と PW を設定
mysql> create user '{ユーザーID}'@'%' identified by '{password}';
ユーザーに権限を付与
※権限を付与しないと Wordpress のデータベース接続ができない
mysql> grant create on *.* to {ユーザーID};
ユーザーが作成されたか確認
mysql> select user, host from mysql.user;
参考サイト

mysql で root の password を変更しようとして Syntax エラー吐かれた

MySQL8.0 では GRANT でユーザ登録ができなかった話

WordPress をインストール

Apache が install されている EC2 インスタンスに SSH ログイン

amazon-linux-extras リポジトリから php を Web サーバーに install

php7.4 に対応したライブラリの install

WordPress を install

WordPress 本体を Apache から見える場所に配置(/var/www/html/)

ファイルの所有者を apache に変更

パブリック IPv4 アドレスで WordPress 管理画面が表示される

amazon-linux-extras リポジトリのソフトウェア一覧を表示
$ amazon-linux-extras
php7.4 を install
$ sudo amazon-linux-extras install -y php7.4
php7.4 に対応したライブラリの install
$ sudo yum install -y php php-mbstring
WordPress を install
$ wget https://wordpress.org/latest.tar.gz
install したフォルダをを解凍
$ tar -xzf latest.tar.gz
WordPress 本体を Apache から見える場所に配置(/var/www/html/)
$ cd wordpress/
$ sudo cp -r * /var/www/html/
ファイルの所有者を apache に変更
$ sudo chown apache:apache /var/www/html/ -R
参考サイト

チュートリアル: Amazon Linux による WordPress ブログのホスティング

WordPress とデータベース接続のエラーでハマった点

WordPress を install して管理画面でデータベース接続ができずにハマりました。その対応策としては mysql のユーザー ID に権限を付与してなかったからです。

データベースを使用する権限を付与 part1
エラー文
「ユーザー xxx にはデータベース wordpress を使用できる権限がありますか ?」
ユーザーに権限を付与
※権限を付与しないと Wordpress のデータベース接続ができない
mysql> grant create on *.* to {ユーザーID};
データベースを使用する権限を付与 part2
エラー文
WordPress データベースエラー: [SELECT command denied to user '{ユーザーID}'@'{host}' for table 'wp_options']
作成したデータベースを書き込めるようにユーザーに権限を付与
mysql> grant all on wordpress.\* to '{ユーザーID}'@'{host}';
Web サーバーから DB サーバーに通信疎通できない場合
エラー文
Authentication plugin 'caching_sha2_password' cannot be loaded: /usr/lib64/mysql/plugin/caching_sha2_password.so: cannot open shared object file: No such file or directory
plugin を「caching_sha2_password 」から「mysql_native_password」に変更する
mysql> ALTER USER '{ユーザーID}'@'{host}' IDENTIFIED WITH mysql_native_password BY '{password}';
参考サイト

Sequel Pro で MySQL にログインできない

Medial Diagnosis And Treatment

EC2 に git をインストール

EC2 Instanceに SSH ログイン
$ sudo yum -y update
$ sudo yum install git
GitHub のアカウント接続する(下記参考サイトを参照)

Apatch の DocumentRoot を変更する

デフォルトでは/var/www/htmlのファイルがページに表示されるので、それを git で pull したファイルを読むように変更する(下記参考サイトを参照)

/var/www/htmlのファイルを/var/tmp/{リポジトリ名/src}にコピーする
$ cp -pR /var/www/html/* /var/lib/{リポジトリ名/src}/
設定ファイル/etc/httpd/conf/httpd.confの書き換え
DocumentRoot "/var/tmp/{リポジトリ名/src}"

<Directory "/var/tmp/{リポジトリ名/src}">
Apatch を再起動
$ sudo systemctl restart httpd
作成したフォルダ・ファイルの所有者を apache に変更
$ sudo chown apache:apache /var/tmp/{リポジトリ名/src}
権限を付与
$ sudo chmod 600 /var/tmp/{リポジトリ名/src}
参考サイト

GitHub ユーザアカウントと GitHub リポジトリ作成 + AWS EC2 から GitHub リポジトリへ push する手順例

【Apache】DocumentRoot を変更しよう

AWS（EC2）で Redmine と Git、Jenkins を使った WordPress 開発環境の構築と公開を行う

以上となります。
これでPublic SubnetのEC2 Instanceの/var/tmp/{リポジトリ名/でgit pullすると開発コードが反映されるかと思います。

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-10T21:18:37+09:00

WordPress環境をDocker(Local)とAWS(Production)で構築

表題の通り、WordPress環境をDockerとAWSで構築したのでその手順についてまとめます。

まとめる内容は以下になります。

WordPressのLocal環境をDockerで構築

Webpackでscssとjsをcompileしてthemesディレクトリにoutput

scssとjsはassetsディレクトリで作業する

開発ファイルはGitで管理する

WordPressのProduction環境をAWSで構築

Public Subnet、Private SubnetでそれぞれEC2 InstanceにWordPressとMySQLをinstall

EC2 InstanceにGitを配置して開発ファイルをPullするとLocal作業が反映される

Local環境

WordPress の Local 環境を Docker で構築

Webpack で js と scss ファイルを compile して themes に output

Docker image の version
image: mysql:8.0.22
image: wordpress:latest
docker-compose.yaml
version: '3'

services:
  db:
    image: mysql:8.0.22
    volumes:
      - db_data:/var/lib/mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: password
      MYSQL_DATABASE: wordpress
      MYSQL_USER: admin
      MYSQL_PASSWORD: password
    networks:
      - wpsite
  phpmyadmin:
    depends_on:
      - db
    image: phpmyadmin/phpmyadmin
    restart: always
    ports:
      - '8080:80'
    environment:
      PMA_HOST: db
      MYSQL_ROOT_PASSWORD: password
    networks:
      - wpsite
  wordpress:
    depends_on:
      - db
    image: wordpress:latest
    ports:
      - '8000:80'
    restart: always
    volumes: ['./../src:/var/www/html']
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: admin
      WORDPRESS_DB_PASSWORD: password
    networks:
      - wpsite
networks:
  wpsite:
volumes:
  db_data:
開発作業

scss と js の作業はassetsディレクトリ内で行う(assets/css/、assets/js/)

assetsディレクトリ内で Webpack 起動

scss と js を変更すると自動で compile されて themes に output

js はruntime.jsとvendors.jsとindex.jsで分割される

jQueryをinstall
webpack.config.js
const webpack = require('webpack');
const path = require('path');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');

const themeName = 'original';

module.exports = {
  mode: 'production',
  entry: {
    index: ['./js/index.js', './css/style.scss'],
  },
  output: {
    filename: 'js/[name].js',
    path: path.resolve(__dirname, `../src/wp-content/themes/${themeName}`),
    publicPath: '/',
  },
  optimization: {
    runtimeChunk: 'single',
    splitChunks: {
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
          chunks: 'all',
        },
      },
    },
  },
  module: {
    rules: [
      {
        test: /\.js?$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-env'],
          },
        },
      },
      {
        test: /\.scss$/,
        use: [
          {
            loader: MiniCssExtractPlugin.loader,
          },
          'css-loader',
          'sass-loader',
        ],
      },
    ],
  },
  plugins: [
    new MiniCssExtractPlugin({
      filename: 'css/style.css',
    }),
    new webpack.ProvidePlugin({
      $: 'jquery',
      jQuery: 'jquery',
    }),
  ],
};
webpack 起動コマンド
$ cd assets
$ npm start
Local 環境

/dockerディレクトリに移動して docker(docker-compose up -d) 起動

http://localhost:8000/が wordpress の local URL

http://localhost:8080/が phpmyadmin の local URL

tree

assets/jsのファイルをsrc/wp-content/themes/original/jsに webpack で compile
├── assets
│   ├── css
│   │   └── style.scss
│   ├── js
│   │   └── index.js
│   ├── node_modules
│   ├── package-lock.json
│   ├── package.json
│   └── webpack.config.js
├── docker
│   └── docker-compose.yaml
└── src
    ├── index.php
    ├── wp-admin
    ├── wp-config-sample.php
    ├── wp-content
        ├── index.php
        ├── languages
        ├── plugins
        ├── themes
            ├── index.php
            ├── original
                └── css
                    └── style.css
                └── js
                    └── index.js
                    └── runtime.js
                    └── vendors.js
gitignore
src/.htaccess
src/wp-config.php
src/wp-content/uploads/
src/wp-content/upgrade/
Docker コマンド

コンテナ表示
$ docker ps
image 一覧
$ docker images
コンテナ起動

-dを実行すると、コンテナはバックグラウンドで起動し、そのまま実行し続けます。
$ docker-compose up -d
コンテナ停止
$ docker-compose down
本番環境

AWS で構築

Public Subnet

Apatch を install して Web サーバーとする

Internet Gatewayで外部からの通信を許可

Private Subnet

NAT Gatewayを介して外部からの通信を可能にするが、サブネットからは通信を不可

MySQL を install して DB サーバーとする

構成図

SSH でログイン
$ ssh -i {秘密鍵}.pem ec2-user@{IPv4パブリックIP}
Web サーバーを踏み台として DB サーバーに SSH ログインして MySQL をinstall

DB サーバーはインバウンドでInternetと接続してない

インバウンドで SSH での接続を許可しているので Web サーバーを踏み台に SSH ログインする

SSH ログインするには pem key を Web サーバーに配置する

NAT GatewayでPublic Subnetを通してInternetに接続できるようにする

DB サーバーにログインして MySQL をinstallする

pem key を scp コマンドで Web サーバーにコピーして配置
$ scp -i {秘密鍵}.pem {秘密鍵}.pem ec2-user@{IPv4パブリックIP}:~/
DB サーバーに SSH ログイン
$ ssh -i {秘密鍵}.pem ec2-user@{プライベート IPv4 アドレス}
参考サイト

Amazon Linux2 の MariaDB を MySQL に差し替えでつまずいた点

AWS EC2 AmazonLinux2 MySQL root ユーザの初期パスワードの確認方法

MySQL コマンド

MySQL 起動
$ sudo service mysqld start
MySQL が起動しているか確認
$ systemctl status mysqld.service
MySQL にログイン
$ mysql -u root -p
初期設定パスワードを変更
mysql> set password for 'root'@'localhost' = '********';
データベースwordpressを作成
CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
ユーザー ID と PW を設定
mysql> create user '{ユーザーID}'@'%' identified by '{password}';
ユーザーに権限を付与
※権限を付与しないと Wordpress のデータベース接続ができない
mysql> grant create on *.* to {ユーザーID};
ユーザーが作成されたか確認
mysql> select user, host from mysql.user;
参考サイト

mysql で root の password を変更しようとして Syntax エラー吐かれた

MySQL8.0 では GRANT でユーザ登録ができなかった話

WordPress をインストール

Apache が install されている EC2 インスタンスに SSH ログイン

amazon-linux-extras リポジトリから php を Web サーバーに install

php7.4 に対応したライブラリの install

WordPress を install

WordPress 本体を Apache から見える場所に配置(/var/www/html/)

ファイルの所有者を apache に変更

パブリック IPv4 アドレスで WordPress 管理画面が表示される

amazon-linux-extras リポジトリのソフトウェア一覧を表示
$ amazon-linux-extras
php7.4 を install
$ sudo amazon-linux-extras install -y php7.4
php7.4 に対応したライブラリの install
$ sudo yum install -y php php-mbstring
WordPress を install
$ wget https://wordpress.org/latest.tar.gz
install したフォルダをを解凍
$ tar -xzf latest.tar.gz
WordPress 本体を Apache から見える場所に配置(/var/www/html/)
$ cd wordpress/
$ sudo cp -r * /var/www/html/
ファイルの所有者を apache に変更
$ sudo chown apache:apache /var/www/html/ -R
参考サイト

チュートリアル: Amazon Linux による WordPress ブログのホスティング

WordPress とデータベース接続のエラーでハマった点

WordPress を install して管理画面でデータベース接続ができずにハマりました。その対応策としては mysql のユーザー ID に権限を付与してなかったからです。

データベースを使用する権限を付与 part1
エラー文
「ユーザー xxx にはデータベース wordpress を使用できる権限がありますか ?」
ユーザーに権限を付与
※権限を付与しないと Wordpress のデータベース接続ができない
mysql> grant create on *.* to {ユーザーID};
データベースを使用する権限を付与 part2
エラー文
WordPress データベースエラー: [SELECT command denied to user '{ユーザーID}'@'{host}' for table 'wp_options']
作成したデータベースを書き込めるようにユーザーに権限を付与
mysql> grant all on wordpress.\* to '{ユーザーID}'@'{host}';
Web サーバーから DB サーバーに通信疎通できない場合
エラー文
Authentication plugin 'caching_sha2_password' cannot be loaded: /usr/lib64/mysql/plugin/caching_sha2_password.so: cannot open shared object file: No such file or directory
plugin を「caching_sha2_password 」から「mysql_native_password」に変更する
mysql> ALTER USER '{ユーザーID}'@'{host}' IDENTIFIED WITH mysql_native_password BY '{password}';
参考サイト

Sequel Pro で MySQL にログインできない

Medial Diagnosis And Treatment

EC2 に git をインストール

EC2 Instanceに SSH ログイン
$ sudo yum -y update
$ sudo yum install git
GitHub のアカウント接続する(下記参考サイトを参照)
git cloneを実行したディレクトリは/var/tmpディレクトリになります。

Apatch の DocumentRoot を変更する

デフォルトでは/var/www/htmlのファイルがページに表示されるので、それを git で pull したファイルを読むように変更する(下記参考サイトを参照)

/var/www/htmlのファイルを/var/tmp/{リポジトリ名/src}にコピーする
$ cp -pR /var/www/html/* /var/lib/{リポジトリ名/src}/
設定ファイル/etc/httpd/conf/httpd.confの書き換え
DocumentRoot "/var/tmp/{リポジトリ名/src}"

<Directory "/var/tmp/{リポジトリ名/src}">
Apatch を再起動
$ sudo systemctl restart httpd
作成したフォルダ・ファイルの所有者を apache に変更
$ sudo chown apache:apache /var/tmp/{リポジトリ名/src}
権限を付与
$ sudo chmod 600 /var/tmp/{リポジトリ名/src}
参考サイト

GitHub ユーザアカウントと GitHub リポジトリ作成 + AWS EC2 から GitHub リポジトリへ push する手順例

【Apache】DocumentRoot を変更しよう

AWS（EC2）で Redmine と Git、Jenkins を使った WordPress 開発環境の構築と公開を行う

以上となります。
これでPublic SubnetのEC2 Instanceの/var/tmp/{リポジトリ名/でgit pullすると開発コードが反映されるかと思います。

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-10T19:34:16+09:00

AWS ANS に向けての勉強　2. VPC

参考

https://www2.slideshare.net/AmazonWebServicesJapan/20201021-aws-black-belt-online-seminar-amazon-vpc

https://aws.amazon.com/jp/vpc/

注意

基本的なところは割愛

概要

AWS上にプライベートネットワーク空間を構築

論理的なネットワーク分離が可能

ネットワーク環境のコントロールが可能

複数のコネクティビティオプションが選択可能

コンポーネント

VPCの構築

サブネットで利用できないIPアドレス(/24の例)

仮想ルータとルートテーブルの関係

パブリックサブネットとプライベートサブネット

セキュリティグループとNACL

セキュリティグループ＝ステートフルFirewall

Network ACLs＝ステートレスFirewall

ステートレスなので戻りの一時ポート（1024～65535など）をoutboundに設定しなければならない

セキュリティコントロール

https://image.slidesharecdn.com/20201021aws-blackbelt-vpc-201023054022/95/20201021-aws-black-belt-online-seminar-amazon-vpc-46-638.jpg?cb=1603431658

ネットワークACLとセキュリティグループ

カスタマーマネージドプレフィックスリスト

CIDRのプレフィックス管理

SG、サブネット、Transit Gatewayのルーティングテーブルで利用可能

RAMで他アカウントから参照可能

バージョン管理も可能

Ingress Routing

VPCに出入りする全トラフィックを特定のEC2を通過させられる＝IDS/IPS、Firewallによる監視・通信制御

サブネット内のDHCP

プライベートIPを固定した場合は、DHCP経由で街頭のIPが割り当てられる

EC2インスタンスのOS上のNIC設定はDHCP)

Route53 resolver(Amazon Provided DNS)

VPC内のEC2からのみ参照可能

VPNや専用線経由で参照する場合、Route53 Resolver for Hybridsで解決

DNS機能の有効かとホストへのDNS名割り当て

Amazon Time Sync Service

169.254.169.123をNTPサーバに設定

リンクローカルアドレスなのでインターネットへのアクセスは不要

IPv6への対応

プライベートにするにはEngress-Only Internet Gatewayを利用

オンプレミスとのハイブリット構成

Site-to-Site VPN構成

ルーティングは静的と動的

ClientVPN構成

Direct Connect構成

ルーティングはBGPのみ

VPCからオンプレミスへのルート設定

インターネットVPN vs 専用線

Transit GAteway

VPCの設計

ポイント

AWSクラウドとVPC

VPC Endpoint

Gateway型

Private Link型

Gateway型 Private Link型比較

Private Linkはオンプレミスにネイティブ対応

NATゲートウェイ

VPCの接続バリエーション

Transit Gateway と PrivateLink はスケーラブル

VPCの運用

VPC Flow Log

VPC Traffic Mirroring

ユースケース

脅威検出

コンテンツモニタリング

問題判別

VPC Flow Logには含まれないパケットの内容の取得が可能

GuardDuty

制限

AWS リージョンごとに、AWS アカウントあたりデフォルト以外の Amazon VPC を最大 5 つ利用できます

Amazon VPC ごとに、最大 4 つのセカンダリ IP アドレス範囲を追加できます

Amazon VPC ごとに 200 までのサブネットを作成できます

AWS リージョンごとに、AWS アカウントあたり Amazon VPC Elastic IP アドレスを最大 5 つ利用できます

その他

 VPC Reachability Analyzer

VPC 内の 2 つのエンドポイント間、または複数の VPC 間で、通信の到達性に関する問題を分析

VPC マネジメントコンソールの左側のナビゲーションから利用

SIEM on Amazon ES

SIEM は Security Information and Event Management の略で、セキュリティ機器、ネットワーク機器、その他のあらゆる機器のデータを収集及び一元管理をして、相関分析によって脅威検出とインシデントレスポンスをサポートするためのソリューション

ユースケース

Amazon GuardDuty を利用して、悪意のあるアクティビティや不正な動作を継続的にモニタリングしているが、検出した脅威について、原因分析のためにイベント発生元サービスのログを調べることが負担になっている

複数のログからインシデントに関連する一連のログだけを抽出して相関分析をしたい

AWS CloudTrail を利用して、ユーザーアクティビティと API 使用状況の追跡のためにログを保存しているが、可視化をしてより深く状況を把握したい

対応している AWS サービスは、AWS CloudTrail、Amazon Virtual Private Cloud (Amazon VPC) Flow Logs、Amazon GuardDuty、AWS WAF、Elastic Load Balancing、Amazon CloudFront、Amazon Simple Storage Service (Amazon S3)、Amazon Route 53 Resolver

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-10T17:12:00+09:00

AWS ANS に向けての勉強　1. AWS Direct Connect

参考

https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-aws-direct-connect-123494683

https://aws.amazon.com/jp/directconnect/?nc=sn&loc=0

https://d1.awsstatic.com/webinars/jp/pdf/services/20200219_BlackBelt_Onpremises_Redundancy.pdf

概要

オンプレミス環境からAWSに対して、専用線を使用してプライベートに接続するサービス

一般的なインターネット接続に対して

安価なアウトバウンドトラフィック（AWS リージョンから AWS Direct Connect を使って送信したデータに対してのみ料金が発生）

安定・良好なネットワーク品質 (一般のネットワークと帯域が異なるので混雑に影響されない）

ユースケース

大規模なデータセットの使用

Direct Connectを使用しない場合、大容量データの送信に対して、ISPへの帯域増強が必要

高い契約更新料

期間契約 ― Direct Connectは、シンプルな従量課金制で一定期間の契約もなく、接続で使用したネットワークポートおよび転送したデータに対してのみの支払いのみ

リアルタイムのデータフィード

ルーティングをユーザがコントロールできるため、一貫性のあるネットワーク体験

音声や動画のアプリケーションなどのネットワークの待ち時間が一定である場合に最適に機能するものに対して効果

ハイブリット環境

プライベート接続が規制要件の場合に、活用

ただしAWS VPNでも実施可能

物理接続

接続方法

専用接続(専有型)

専用線でDirect Connect Locationに接続

東京リージョンでは Equinix TY2(東京) / OS1(大阪) ・・・など4つ

Connectionは　1Gbps / 10Gbps　のポート速度をサポート

接続パターン

Link Aggregation Group (LAG)

Link Aggregation Control Protocol (LACP) を使用して複数の接続を 1 つの AWS Direct Connect エンドポイントに集約し、これらを 1 つのマネージド接続として扱えるようにする論理インターフェイス

制約

すべての接続が専用接続

すべての接続が同じ帯域幅

最大４つまで

同じAWS Direct Connect エンドポイントで終了

Cloud Watch でメトリクスが扱える

LOAの発行場所の記載 https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/lags.html

専用接続(共有型)

Cloud Watch でメトリクスが扱えない

LOAの発行場所の記載がなく、パートナー名が表示

ホスト接続

Hosted Connectionと呼ぶ仮想的なConnectionをパートナーがユーザに提供

1Gbps以下の接続を提供する場合に利用

50, 100, 200, 300, 400, 500 Mbpsのいずれかの帯域を専有可能

Hosted Connection の中のVIFを一つだけ、ユーザで自由に設定できる

Cloud Watch でメトリクスが扱えない

LOAの発行場所の記載がなく、パートナー名が表示

異なる回線サービスで冗長をとる場合、回線ごとの経路広報タイプが異なると予期せぬ経路の偏りの原因となるので注意

仮想インターフェース (Virtual Interface = VIF)

Connection（物理接続）を通してAWSリソースにアクセスするための論理インターフェース

AWSとユーザルータ間でBGP¹ピアを確立し、経路交換するために必要

VLAN IDを持つ

private / public

Private VIF: VPCへプライベートアドレスを介した接続を提供する

Public VIF: AWSの全リージョンへパブリックIPを介した接続を提供するのがPublic VIF

接続

クロスアカウント利用

Connection を所有すしているアカウントからほかのアカウントに対してVIFを提供することが可能

プライベート接続

ユーザルータでBGP、MD5認証、IEEE802.1q VLANのサポートが必要

VPC のCIDR（IPv4/v6)がAWSから広告される

Jumbo Frame²(MTU=9001)をサポート

VPN接続、インターネットゲートウェイ経由のトラフィックは1500MTUに制限されてしまうので、DirectConnectが良い

Private VIFによるマルチVPC接続

オンプレミスを複数のVPCへ接続するために複数のPrivateVIFを使用

複数の異なるＡＷＳアカウントのＶＰＣへオンプレミスから接続可能

Direct Connection Location に紐づけられたリージョンのVPCのみ接続可能

オンプレミスからの接続



パブリック接続

Public VIF を使用して中国を除く全リージョンのパブリックサービスへの接続を提供

オンプレミスのプライベートアドレスをAWS提供のパブリックIPアドレスへNAT

中国を除く全リージョンのAWSサービスのパブリックIPアドレスをAWSから広告

Public VIFによるパブリックサービスへの接続

AWS Direct Connect Gateway

パートナー経由のDirect Connect

高可用性

冗長化の選択肢

https://d1.awsstatic.com/webinars/jp/pdf/services/20200219_BlackBelt_Onpremises_Redundancy.pdf

デュアルロケーション



複数のDirect Connectによる冗長化

VGWは内部的に冗長化されているので冗長化の意識は不要

同一ロケーションの冗長化は旧来の方法。今はベストプラクティスではない

BGPパス属性を用いた経路制御

TIPS: 一部のルーターOSでは、Graceful Restart*の機能がデフォルトで有効になっているBFDとGraceful Restartを併用すると、意図した障害検出が出来ず、切り替えに時間がかかるので、無効にしておくことを強く推奨

障害時の経路切り替え時間の短縮



コスト抑制条件に適用した冗長化

Standbyへ切り替わり時には、通信品質の劣化を許容することも必要

パートナーのサービスによっては、意図する経路設計が出来ない事もあるので、事前に確認が必要

BGPのASパス属性でVPN側を優先したとしても、AWS→オンプレミス方向の通信は、必ずDirect Connectが優先される

パートナー網を経由した冗長化

Direct Connect Gatewayに対する冗長化

本番と開発のリソースを分ける観点から、DXGWを分けたい要望があるが、 VGWアタッチの制約で不可

（そもそもDirectConnectGatewayは内部で冗長されている)

Transit Gatewayに対する冗長化

TGWを分ける必要が無い理由: HyperPlane

大量のリソースを仮想的に分割して提供

TIPS: TGWを分ける事で、利用するVPC CIDRごとに使う物理線を分割可能

パートナのサービスにおいて、１つしかVPCが利用できない場合など

障害に対する対応

ゲームデー



回復性向上



各種制限



BGP（Border Gateway Protocol）。パケットのあて先を正確に把握し、維持していくための経路制御技術の代表的なプロトコル。参考：https://www.nic.ad.jp/ja/newsletter/No35/0800.html ↩

ネットワーク接続の最大送信単位 (MTU)は通常1500バイトだが、パケット当たりのペイロードサイズを拡張し、パケットオーバーヘッド以外のパケットの割合を高めることで1500バイト以上のデータを送信可能なもの。 ↩

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-10T16:38:15+09:00

Developers.IOの`【2021年】AWS全サービスまとめ`をBS4で一覧にする

Developers.IOの【2021年】AWS全サービスまとめの記事について、Beautiful Soupを利用して一覧にする方法です。

import requests
from bs4 import BeautifulSoup
import re
import pandas as pd

res = requests.get('https://dev.classmethod.jp/articles/aws-summary-2021/')

soup = BeautifulSoup(res.text, 'html.parser')

all_services = []

categories = soup.find_all('h2')

for category in categories:
    category_name = category.text
    if category_name == 'まとめ':
        break
    for el in category.next_siblings:
        if el.name == 'h2':
            break
        if el.name == 'h3':
            service_name = el.text
            service_name = re.sub('[\r\n]', '', service_name)
            service_name = re.sub('^[\s]+', '', service_name)
            service_name = re.sub('[ ]+$', '', service_name)
            service_name = re.sub('\s*\[.+\]\s*', '', service_name)

            if not service_name or service_name.startswith('EVENT') or service_name.startswith('Session Summary:'):
                continue

            desc_el = el.next_element.next_element.next_element
            desc = desc_el.text

            all_services.append({
                'category_name': category_name,
                'service_name': service_name,
                'desc': desc
            })

print(len(all_services))

all_services_df = pd.DataFrame(all_services)
print(all_services_df)
all_services_df.to_csv('aws_all_services.csv', encoding='ms932')

参考文献

【2021年】AWS全サービスまとめ

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-10T15:50:08+09:00

AWS SAA-C02 受験対策(1) Route53

0. はじめに

AWS SAAのお勉強をする中で学んだことをメモしています。
（試験に出そうで自分の理解の足りなさそうな部分のみピックアップしています）
※ 間違い等ありましたらコメントなどで指摘してください

■前提
SIer 7年目
AWSの有名どころのサービス(EC2,S3,RDS..)を若干齧ったことある程度

■教材
黒本
徹底攻略 AWS認定ソリューションアーキテクト – アソシエイト教科書

Udemy
【SAA-C02版】AWS 認定ソリューションアーキテクトアソシエイト模擬試験問題集（6回分390問）

その他公式のドキュメント etc..

1. Route53とは

可用性の高いDNSを提供するマネージドサービス。
外部向けのパブリックホストゾーンと内部向けのプライベートホストゾーンがある。

機能①　DNS機能
Route53は、ELBやCloudFrontに対して、ZoneApexレコードをAレコードで指定することができる。
■イメージ
example.com(サブドメインを含まないルートドメイン) ⇒ Aレコード(elasticloadbalancing.us-east-2.amazonaws.com)

機能②　ポリシーによる通信制御
ルーティングポリシーを設定することでRoute53がクエリに対してどう応答するか設定できる。

2. 主なルーティングポリシー

ルーティングポリシー特徴

シンプルルーティング・ドメインで特定の機能を実行する単一のリソースがある場合に使用します
・複数値を１つのレコードに指定するとランダムな順序でルーティングされる

レイテンシールーティング・最もレイテンシーが低いリソースへルーティングする
・基本的には位置的に近いリージョンで解決される

加重ルーティング・複数のリソースに対して加重度を設定し、指定した比率に応じて処理を分散する

複数値回答ルーティング・ランダムに選ばれた最大 8 つの正常なレコードを使用して Route 53 が DNS クエリに応答する場合に使用します。

位置情報ルーティング・ユーザーの位置に基づいてトラフィックをルーティングする場合に使用します。
・特定の国、地域にローカライズされたコンテンツを表示したい場合等に使用。

地理的近接性ルーティング・リソースの場所に基づいてトラフィックをルーティングし、必要に応じてトラフィックをある場所のリソースから別の場所のリソースに移動する場合に使用します。

フェイルオーバールーティング・アクティブ/パッシブフェイルオーバーを構成する場合に使用します。

参考: AWS 開発者ガイドルーティングポリシーの選択

ルーティングポリシー	特徴
シンプルルーティング	・ドメインで特定の機能を実行する単一のリソースがある場合に使用します・複数値を１つのレコードに指定するとランダムな順序でルーティングされる
レイテンシールーティング	・最もレイテンシーが低いリソースへルーティングする・基本的には位置的に近いリージョンで解決される
加重ルーティング	・複数のリソースに対して加重度を設定し、指定した比率に応じて処理を分散する
複数値回答ルーティング	・ランダムに選ばれた最大 8 つの正常なレコードを使用して Route 53 が DNS クエリに応答する場合に使用します。
位置情報ルーティング	・ユーザーの位置に基づいてトラフィックをルーティングする場合に使用します。・特定の国、地域にローカライズされたコンテンツを表示したい場合等に使用。
地理的近接性ルーティング	・リソースの場所に基づいてトラフィックをルーティングし、必要に応じてトラフィックをある場所のリソースから別の場所のリソースに移動する場合に使用します。
フェイルオーバールーティング	・アクティブ/パッシブフェイルオーバーを構成する場合に使用します。

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-10T14:03:41+09:00

EC2の自動デプロイが反映されない

前書き

タイトルにあるようにAWSを使って自動デプロイにしたところ変更が反映されておらず死ぬほど焦りました笑
調べていると他の人もなっている人たちがいたのでよくあることなんだなーと学んだと共に今後同じことがあったときに焦ることがないよう、備忘録として残しておきます。

環境

AWS EC2
Ruby 2.6.5
Rails 6.0.3.3
capistrano

解決法

EC2インスタンスを再起動することで解決します。
自動デプロイを複数回行うと変更が反映されないことがあるためその際はインスタンスの再起動を行います。
再起動手順はこちらの記事にわかりやすく解説されています↓
https://qiita.com/qolayumusou/items/a34cccbb07802c94eeef

まだやることがあった

インスタンスの再起動を行った際はデータベースとNginxの再起動も忘れずに行う必要があります。
EC2内のターミナルで実行します！
[ec2-user@ip-000-00-00-000 ~]$ sudo systemctl restart mariadb 
[ec2-user@ip-000-00-00-000 ~]$ sudo systemctl restart nginx
終わりに

AWSは実際の業務で触れることが多いと思われるので今のうちに少しでも慣れていければと思いました。

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-10T12:58:09+09:00

RDS

＃概要
・フルマネージドなリレーショナルデータベース
・シンプルかつ迅速にスケール
・高速。安定したパフォーマンス
・低コスト、従量課金

特徴

・シンプルな構築
　オプション
　　・マルチAZデプロイメント
　　・リードレプリカ
　　・バックアップ（スナップショット）
　　・監視（Cloudwatch）
　　・拡張モニタリング
・高い可用性
　マルチAZデプロイメント
　　・同期レプリケーション　＋　自動フェイルオーバー
　　　→アプリ側での対処は必要なし
　　　→スタンバイ状態のDBはアクセス負荷
・パフォーマンスの向上
　リードレプリカ
　　→レプリカDBで読み取り処理をスケールアウト
　　→MySQL、MariaDB、PostgreSQL、Aurora、Oracle、SQLserverに対応
・スケールアップ
・運用負荷の軽減
　バックアップ
　　→スナップショットとリストア
　
・セキュリティ

マルチAZの障害時の動作

AZ機能はデータベースの更新を異なるAZに配置されたプライマリーとホットスタンバイを同時に行うことで、耐久性と可用性を高める

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-10T10:28:20+09:00

Amazon Aurora クラスター/インスタンス作成方法メモ

AWS CLIを用いたAmazon Auroraのクラスター/インスタンス作成方法についてメモする。

作成手順

以下のようなMulti-AZ構成のDBクラスター・インスタンスを作成する。

前提条件

VPC、サブネット、セキュリティグループは作成済みであるものとする。

1. クラスターパラメータグループ作成

クラスターパラメータグループtest-db-cluster-param-groupを作成する。
aws rds create-db-cluster-parameter-group \
    --db-cluster-parameter-group-name test-db-cluster-param-group \
    --db-parameter-group-family aurora-mysql5.7 \
    --description "My Test DB Cluster Parameter Group"
※要件に応じてパラメータを変更する。
aws rds modify-db-cluster-parameter-group \
    --db-cluster-parameter-group-name test-db-cluster-param-group \
    --parameters \  "ParameterName=server_audit_logging,ParameterValue=1,ApplyMethod=pending-reboot" \   "ParameterName=server_audit_logs_upload,ParameterValue=1,ApplyMethod=pending-reboot"
2. インスタンスパラメータグループ作成

インスタンスパラメータグループtest-db-param-groupを作成する。
aws rds create-db-parameter-group \
    --db-parameter-group-name test-db-param-group \
    --db-parameter-group-family aurora-mysql5.7 \
    --description "My Test DB Parameter Group
※要件に応じてパラメータ変更する。
aws rds modify-db-parameter-group \
    --db-parameter-group-name test-db-param-group \
    --parameters \
    "ParameterName=max_connections,ParameterValue=250,ApplyMethod=pending-reboot" \     
    "ParameterName=max_allowed_packet,ParameterValue=1024,ApplyMethod=pending-reboot"
3. サブネットグループ作成

サブネットグループtest-db-subnet-groupを作成する。

※作成済みDB用サブネットを指定する。
aws rds create-db-subnet-group \
    --db-subnet-group-name test-db-subnet-group \
    --db-subnet-group-description "My Test DB subnet group" \
    --subnet-ids ${SUBNET_DB_A} ${SUBNET_DB_B}
4. クラスター作成

DBクラスターtest-db-clusterを作成する。
aws rds create-db-cluster --db-cluster-identifier test-db-cluster --engine aurora-mysql \
--engine-version 5.7.12 \
--master-username ${USER_NAME} \
--master-user-password ${PASSWORD} \
--db-subnet-group-name test-db-subnet-group \
--vpc-security-group-ids ${SG_DB} \
--availability-zones ${REGION_ID}a ${REGION_ID}c
5. インスタンス作成

AZ-a系統のインスタンスを作成する。
aws rds create-db-instance --db-instance-identifier test-instance-a \
--db-cluster-identifier test-db-cluster \
--engine aurora-mysql \
--db-instance-class db.r4.large \
--availability-zone ${REGION_ID}a
AZ-c系統のインスタンスを作成する。
aws rds create-db-instance --db-instance-identifier test-instance-c \
--db-cluster-identifier test-db-cluster \
--engine aurora-mysql \
--db-instance-class db.r4.large \
--availability-zone ${REGION_ID}c
参考情報

Amazon Aurora DB クラスターの作成

DB パラメータグループおよび DB クラスターパラメータグループを使用する

CLIリファレンス

create-db-cluster-parameter-group

modify-db-cluster-parameter-group

create-db-cluster

create-db-instance

create-db-subnet-group

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-10T09:34:32+09:00

Lambda layer（python）で5分くらい遊ぶ

まとめ

ディレクトリ構成: python/layer/function.py

インポート: from layer import layer1

Layer化したいファイルの用意
function.py
def sum(x:int, y:int) -> int:
    return x + y
Layerを利用する関数の用意
lambda_function.py
import json
from layer import function

def lambda_handler(event, context):
    # TODO implement
    return {
        'statusCode': 200,
        'body': function.sum(1,2)
    }
さいごに

python/ ディレクトリ以下に配置して、その先をimportする

Zip化する際に共通系がそこに入るようにコーディネートしなければならないのめんどくさい

そんなモジュールないぜ、ってPython的に言われるだけで、ちょっとデバッグしづらい

Lambda視点からのエラーメッセージを出力してくれたらもう少し親切なのに

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-10T08:11:38+09:00

RDSでMySQLデータベースを作るための覚書

はじめに

AWSのRDSにMySQLのデータベースを作ります。こちらで作成したEC2から接続できるようにします。

全体概要

下記のツリーのようにオブジェクトを作っていきます。「AAA」は任意の名前に読み替えしてください。

VPC AAAvpc01 10.0.0.0/16 こちらで作ったものを使います。

EC2 RDSに適用するためのセキュリティグループを作ります。

セキュリティグループ AAASGRDS01

MYSQL/Aurora 3306/TCP from 0.0.0.0/0

RDS

DBサブネットグループ AAADBSUB01

MySQLデータベース aaamysql01

MySQLデータベースの作成

先にセキュリティグループとDBサブネットを作ってからRDSを作成します。

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

EC2のセキュリティグループ新規作成画面を開きます。セキュリティグループの名前と説明を入れてVPCはRDSの置き場所を選びます。

セキュリティグループのインバウンドルールを追加します。タイプはMYSQL/Auroraでソースを0.0.0.0/0とします。アウトバウンドはそのままでセキュリティグループを作成します。

セキュリティグループが完成しました。

DBサブネットグループの作成

RDSのサブネットグループメニューからDBサブネットグループの作成画面を開きます。名前と説明を入力します。

VPCに対象のVPCを入力して、このVPCに関連するすべてのサブネットを追加します。作成ボタンを押します。

DBサブネットグループが完成しました。

データベースを作成する

RDBのデータベース作成画面を開きます。エンジンのタイプでMySQLを選択します。

テンプレートで無料利用枠を選びます。DBインスタンス識別子でデータベース名を入力します。

認証情報としてマスターユーザー名とパスワードを入力します。

VPCは対象のVPC、先ほど作ったDBサブネットグループを選択します。パブリックアクセスはなしにしました。

セキュリティグループは既存で先ほど作成したもの、アベイラビリティゾーンはどれか一つを選択してデータベースの作成を行います。

データベースの作成が正常に始まりました。これは10分ほど時間がかかります。

MySQLクライアントの作成

既存のEC2サーバから接続テストを行うにあたり、こちらを参考にMySQLクライアントをインストールしました。
$  sudo yum localinstall -y https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm
$  yum info mysql
$  sudo yum-config-manager --disable mysql57-community
$  sudo yum-config-manager --enable mysql80-community
$  sudo yum install -y mysql-community-client
$  mysql --version
接続テスト

下記のように接続テストを行います。HOSTNAMEは作成したデータベースの接続とセキュリティの設定にあるエンドポイント(例:aaamysql01.c3xhaaxcxwwl.ap-northeast-1.rds.amazonaws.com)を入力します。
$ mysql -h HOSTNAME -P 3306 -u admin -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 13
Server version: 8.0.20 Source distribution

Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>
EC2から接続ができました！

おわりに

データベースのセキュリティグループでインバウンドのソースを無制限にしていますが、RDSのパブリックアクセスを「なし」にしたので、VPC内からのみ接続可能になります。パブリックアクセスをありにするとインターネットからデータベース接続が可能になると思います。

データベースのテンプレートとして無料枠を利用して作成しましたが、本番環境を選ぶとマルチAZにより可用性を高めることができると思います。

参考文献

https://tsukasa-blog.com/programming/django-ec2-apache/

https://qiita.com/na0AaooQ/items/7c69a88c80f1efb4cad3

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/CHAP_MySQL.html

https://qiita.com/ponsuke0531/items/3ae69a9d477809c00917

https://qiita.com/suzuki_y/items/3261ffa9b67410803443

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-10T01:46:16+09:00

AWS　WEBサーバー構築

はじめに

自作Laravelアプリを公開するべくAWSで環境構築した作業メモです。
AWSアカウント作成、AWSネットワーク構築　を事前にやってます。
（投稿順序が逆転してますが、今後投稿予定）

WEBサーバー構築

EC2インスタンスを設置する

AWSマネジメントコンソールに入って、サービスの検索窓にEC2と入力し、EC2のダッシュボードに移動する。

左メニューのインスタンスを押し、右上のインスタンス起動を押す。

AMI作成

無料枠であるAmazon Linux 2 AMI (HVM), SSD Volume Typeを選択する。

インスタンスタイプの選択

t2.microにチェックを入れ、「次のステップ：インスタンスの詳細の設定」を押す。(デフォルトで選択されている)

インスタンスの詳細の設定

インスタンス数：そのまま（１）
購入のオプション：そのまま（チェックなし）
ネットワーク：作成したVPC
サブネット：作成したパブリックサブネット
自動割り当てパブリック：有効
配置グループ：そのまま（チェックなし）
キャパシティーの予約：なし
ドメイン結合ディレクトリ：そのまま（ディレクトリなし）
IAM ロール：そのまま（なし）
CPU オプション：そのまま（チェックなし）
シャットダウン動作：停止
停止 - 休止動作：そのまま（チェックなし）
終了保護の有効化：そのまま（チェックなし）
モニタリング：そのまま（チェックなし）
テナンシー：そのまま（共有）
Elastic Inference：そのまま（チェックなし）
クレジット仕様：そのまま（チェックなし）
ファイルシステム：そのまま（設定なし）

ネットワークインターフェイス
プライマリIP：10.0.10.10

高度な詳細
特になにもしない

右下の「次のステップ：ストレージの追加」を押す。

ストレージの追加

サイズ：そのまま（８）
ボリュームタイプ：そのまま（汎用SSD）
終了時に削除：そのまま（チェック）
暗号化：そのまま（暗号化なし）

右下の「次のステップ：タグの追加」を押す。

タグの追加

キー：Name
値：aws-and-infra-web
インスタンス：そのまま（チェック）
インスタンス：ボリューム（チェック）

右下の「次のステップ：セキュリティグループの設定」を押す。

セキュリティグループの設定

セキュリティグループの割り当て：そのまま（新しいセキュティグループを作成する）
セキュリティグループ名：aws-and-infra-web
説明：aws-and-infra-webに変える（日付はそのまま）

右下の「確認と作成」を押す。

インスタンス作成の確認

これまで設定した内容が表示されるので、ざっと確認する。だいたい合っていれば、右下の「起動」を押す。

SSHキーペアの設定

新しいキーペアの作成を選択
キーペア名：aws-and-infra-ssh-key
キーペアのダウンロードを押し、デスクトップに保存する。
※このファイルは後でダンロードし直せないので消さないように注意

「インスタンスの作成」を押す。

が、エラー発生。

インスタンスの詳細の設定のネットワークインターフェースで設定した、サブネットのIPが間違っていた。
誤10.0.10.0
正10.0.10.10

修正後、インスタンスの作成をし成功。

インスタンス作成完了！！

SSHでEC2に接続

Macの場合
$ chmod 600 Desktop/aws-and-infra-ssh-key.pem
ターミナルで下記コマンドを実行する。
秘密鍵ファイルの読み書きを厳しくする。

AWマネジメントコンソールのEC2ダッシュボードに入る。

作成したインスタンスを選択すると下に表示される詳細のパブリックIPv4アドレスを確認する。

ログインコマンドを実行する。
$ ssh -i Desktop/aws-and-infra-ssh-key.pem ec2-user@52.194.251.7
The authenticity of host '52.194.251.7 (52.194.251.7)' can't be established.
ECDSA key fingerprint is SHA256:sG+KNgRElh3SiLbYAHdi0dX6XLnp5A+kZrGrVjApSsE.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
と聞かれるのでyesを。（これは初回のみ）
       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/
2 package(s) needed for security, out of 5 available
Run "sudo yum update" to apply all updates.
と表示されれば無事ログイン成功。

Apacheのインストール

EC2インスタンスのライブラリのアップデートをする。
$ sudo yum update -y
Apacheのインストール。
$ sudo yum -y install httpd
Apacheの起動。
$ sudo systemctl start httpd.service
起動確認。
$ sudo systemctl status httpd.service
active (running)と表示されれば起動完了。

Apache自動起動の設定。
$ sudo systemctl status httpd.service
確認。
$ sudo systemctl is-enabled httpd.service
is-enabledと表示されればOK。

ファイアウォールの設定

まず今の状態でブラウザで確認する。

応答せず開けませんとなる。

AWSマネジメントコンソールのEC2ダッシュボードを開く。
該当のVPCを選択し、下に表示されるセキュリティグループのリンクを押す。

インバウンドの編集を押し、

ルールの追加を押す。

タイプ：HTTP
ソース：任意の場所
右下の「ルールを保存」を押す。

再度、ブラウザで確認するとApacheデフォルトページが表示される。

セキュリティグループのポート80をあける。

IPアドレスの固定　ElasticIP

AWSマネジメントコンソールのEC2ダッシュボードを開く。
左メニューのElasticIPを押す。

「ElasticIPアドレスの割り当て」を押す。

そのまま、右下の「割り当て」を押すと割り当て完了。

次に割り当てられたElasticIPを選択し、
右上の「ElasticIPアドレスの関連付け」を押す。

リソースタイプ：そのまま（インスタンス）
インスタンス：該当のもの選択
プライベートPアドレス：該当のもの選択
再関連付け：そのまま（チェックなし）

右下の「関連付ける」を押し完了。

割り当てられたIPv4アドレス(概要に表示されている)をブラウザで接続すると、先ほどと同じApache画面が表示される。ElasticIPの固定成功！

※注意
Elacticアドレスはインスタンスに紐づいていないと課金されます。
紐づいてない時や、インスタンス起動停止した時は、アクションから「アドレスの関連付けの解除」→「アドレスの解放」を実施する。

後片付け

料金がかからないように。

Elasticアドレスの解放

AWSマネジメントコンソールのEC2ダッシュボードを開く。
左メニューのElasticIPを押す。

アクションから「アドレスの関連付けの解除」を押す。

「アドレスの関連付けの解除」を押す。
戻ったページで関連付けられたインスタンスが「ー」となっていることを確認。

アクションから「ElasticIPアドレスの解放」を押す。

「解放」を押す。

一覧に表示がなくなればOK。

インスタンスの停止

AWSマネジメントコンソールのEC2ダッシュボードを開く。
左メニューのインスタンスを押す。

アクションから「インスタンスの状態を管理」を押す。

停止にチェックを入れ、「状態の変更」を押す。

「停止」を押す。

一覧のインスタンスの状態が「停止済み」となればOK。

これでElasticアドレスからも、EC2インスタンスからも料金が発生しなくなる。

参考

https://www.udemy.com/course/aws-and-infra/learn/lecture

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-10T01:46:16+09:00

AWS WEBサーバー構築

はじめに

自作Laravelアプリを公開するべくAWSで環境構築した作業メモです。
AWSアカウント作成、AWSネットワーク構築　を事前にやってます。
（投稿順序が逆転してますが、今後投稿予定）

手順

EC2インスタンスを設置する

SSHでEC2に接続

Apacheのインストール

ファイアウォールの設定

IPアドレスの固定　ElasticIP

WEBサーバー構築

EC2インスタンスを設置する

AWSマネジメントコンソールに入って、サービスの検索窓にEC2と入力し、EC2のダッシュボードに移動する。

左メニューのインスタンスを押し、右上のインスタンス起動を押す。

AMI作成

無料枠であるAmazon Linux 2 AMI (HVM), SSD Volume Typeを選択する。

インスタンスタイプの選択

t2.microにチェックを入れ、「次のステップ：インスタンスの詳細の設定」を押す。(デフォルトで選択されている)

インスタンスの詳細の設定

インスタンス数：そのまま（１）
購入のオプション：そのまま（チェックなし）
ネットワーク：作成したVPC
サブネット：作成したパブリックサブネット
自動割り当てパブリック：有効
配置グループ：そのまま（チェックなし）
キャパシティーの予約：なし
ドメイン結合ディレクトリ：そのまま（ディレクトリなし）
IAM ロール：そのまま（なし）
CPU オプション：そのまま（チェックなし）
シャットダウン動作：停止
停止 - 休止動作：そのまま（チェックなし）
終了保護の有効化：そのまま（チェックなし）
モニタリング：そのまま（チェックなし）
テナンシー：そのまま（共有）
Elastic Inference：そのまま（チェックなし）
クレジット仕様：そのまま（チェックなし）
ファイルシステム：そのまま（設定なし）

ネットワークインターフェイス
プライマリIP：10.0.10.10

高度な詳細
特になにもしない

右下の「次のステップ：ストレージの追加」を押す。

ストレージの追加

サイズ：そのまま（８）
ボリュームタイプ：そのまま（汎用SSD）
終了時に削除：そのまま（チェック）
暗号化：そのまま（暗号化なし）

右下の「次のステップ：タグの追加」を押す。

タグの追加

キー：Name
値：aws-and-infra-web
インスタンス：そのまま（チェック）
インスタンス：ボリューム（チェック）

右下の「次のステップ：セキュリティグループの設定」を押す。

セキュリティグループの設定

セキュリティグループの割り当て：そのまま（新しいセキュティグループを作成する）
セキュリティグループ名：aws-and-infra-web
説明：aws-and-infra-webに変える（日付はそのまま）

右下の「確認と作成」を押す。

インスタンス作成の確認

これまで設定した内容が表示されるので、ざっと確認する。だいたい合っていれば、右下の「起動」を押す。

SSHキーペアの設定

新しいキーペアの作成を選択
キーペア名：aws-and-infra-ssh-key
キーペアのダウンロードを押し、デスクトップに保存する。
※このファイルは後でダンロードし直せないので消さないように注意

「インスタンスの作成」を押す。

が、エラー発生。

インスタンスの詳細の設定のネットワークインターフェースで設定した、サブネットのIPが間違っていた。
誤10.0.10.0
正10.0.10.10

修正後、インスタンスの作成をし成功。

インスタンス作成完了！！

SSHでEC2に接続

Macの場合

ターミナルで下記コマンドを実行する。
秘密鍵ファイルの読み書きを厳しくする。
$ chmod 600 Desktop/aws-and-infra-ssh-key.pem
AWマネジメントコンソールのEC2ダッシュボードに入る。

作成したインスタンスを選択すると下に表示される詳細のパブリックIPv4アドレスをコピーする。

ログインコマンドを実行する。@以下にコピーしたIPを入力。
$ ssh -i Desktop/aws-and-infra-ssh-key.pem ec2-user@52.194.251.7
The authenticity of host '52.194.251.7 (52.194.251.7)' can't be established.
ECDSA key fingerprint is SHA256:sG+KNgRElh3SiLbYAHdi0dX6XLnp5A+kZrGrVjApSsE.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
と聞かれるのでyesを。（これは初回のみ）
       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/
2 package(s) needed for security, out of 5 available
Run "sudo yum update" to apply all updates.
と表示されれば無事ログイン成功。

Apacheのインストール

EC2インスタンスのライブラリのアップデート。
$ sudo yum update -y
Apacheのインストール。
$ sudo yum -y install httpd
Apacheの起動。
$ sudo systemctl start httpd.service
起動確認。
$ sudo systemctl status httpd.service
active (running)と表示されれば起動完了。

Apache自動起動の設定。
$ sudo systemctl status httpd.service
確認。
$ sudo systemctl is-enabled httpd.service
is-enabledと表示されればOK。

ファイアウォールの設定

まず今の状態でブラウザで確認する。
※先ほどコピーしたIPで

応答せず開けませんとなる。

AWSマネジメントコンソールのEC2ダッシュボードを開く。
該当のVPCを選択し、下に表示されるセキュリティグループのリンクを押す。

「インバウンドルールを編集」を押し、

「ルールの追加」を押す。

タイプ：HTTP
ソース：任意の場所
右下の「ルールを保存」を押す。

再度、ブラウザで確認するとApacheデフォルトページが表示される。

IPアドレスの固定　ElasticIP

AWSマネジメントコンソールのEC2ダッシュボードを開く。
左メニューのElasticIPを押す。

「ElasticIPアドレスの割り当て」を押す。

そのまま、右下の「割り当て」を押すと割り当て完了。

次に割り当てられたElasticIPを選択し、
右上の「ElasticIPアドレスの関連付け」を押す。

リソースタイプ：そのまま（インスタンス）
インスタンス：該当のもの選択
プライベートPアドレス：該当のもの選択
再関連付け：そのまま（チェックなし）

右下の「関連付ける」を押し完了。

割り当てられたIPv4アドレス(概要に表示されている)をブラウザで接続すると、先ほどと同じApache画面が表示される。ElasticIPの固定成功！

※注意
Elacticアドレスはインスタンスに紐づいていないと課金されます。
紐づいてない時や、インスタンス起動停止した時は、アクションから「アドレスの関連付けの解除」→「アドレスの解放」を実施する。

後片付け

料金がかからないように。

Elasticアドレスの解放

AWSマネジメントコンソールのEC2ダッシュボードを開く。
左メニューのElasticIPを押す。

アクションから「アドレスの関連付けの解除」を押す。

「アドレスの関連付けの解除」を押す。
戻ったページで関連付けられたインスタンスが「ー」となっていることを確認。

アクションから「ElasticIPアドレスの解放」を押す。

「解放」を押す。

一覧に表示がなくなればOK。

インスタンスの停止

AWSマネジメントコンソールのEC2ダッシュボードを開く。
左メニューのインスタンスを押す。

アクションから「インスタンスの状態を管理」を押す。

停止にチェックを入れ、「状態の変更」を押す。

「停止」を押す。

一覧のインスタンスの状態が「停止済み」となればOK。

これでElasticアドレスからも、EC2インスタンスからも料金が発生しなくなる。

参考

https://www.udemy.com/course/aws-and-infra/learn/lecture

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-10T01:44:57+09:00

AWS ホワイトペーパー翻訳

はじめに

仕事でAWSを使っています。
そろそろ
* 「業務で得た知識を整理したい」
* 「資格がないと箔が付かない」
などの理由で何かしら資格が欲しいのですが、イキりたいので最高峰のSAPを目指して勉強していこうと思います。
AWS Certified Solutions Architect - Professional

下記、私のスペックです。
* 未経験 ⇒ IT業界9ヶ月目
* AWSに関わって4ヶ月程度

どのように達成するか

先駆者の記事を読むと、次の方法が有効そうでした。
➀ Udemyの模擬試験(有料)
➁ SAP唯一の対策本(2020/6発行)
➂ ホワイトペーパー(Black Belt)の熟読

私は業務でよく使う超有名サービス(EC2, RDS, etc...)しか詳しくない為、全体像を掴みます。
なので、今後暫くは➂のホワイトペーパーの翻訳および要約の記事を書いてアウトプットしていこうと思います。

4月くらいにはとりたいなぁ。。。
資格取得後に、私の記事が他の皆様の勉強の助けになればと思います。
~~※Qiita初めてなので、温かく見守っていて下さい。~~

では。
（2021/01/10）

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-10T00:01:03+09:00

VPCピアリングとは

勉強前イメージ

VPCで外部ネットワークと接続するときのなんとか・・・？

調査

VPCピアリングとは

異なるVPCを接続することが出来ます。
複数のAWSのコンテンツをまとめたり、複数のAWS間で通信が行うことが出来ます。
異なるAWSアカウント(クロスアカウント)間でもVPCピアリングを行うことが出来ます
また、複数のVPCとピアリングすることがデフォルトで50まで出来ます

注意しないといけないこと

CIDRブロックが重複しているVPC間のペアリングは出来ない

異なるリージョン間でのVPCペアリングはIPv6非対応

勉強後イメージ

外部ネットワークじゃなくて
VPC間のネットワーク通信をさせるためのものだった・・・
実際に作ってみた方がしっくり来るかも

参考

Amazon VPC同士の接続パターンまとめ (Whitepaper参照）

VPCピアリングを作りながら学んでみた

Amazon VPCのピアリング接続

VPC ピア機能とは

　 Tweet
Qiitaで続きを読む

20210110のAWSに関する記事は19件です。

EC2でartisanが作動しない時にやること

背景

結論：バージョンとcomposer.json

composer.jsonの中身を書き換える

バージョンを合わせる

composerをインストールする

最後に

EC2にLaravelプロジェクトをデプロイする際、artisanが実行できない時にやること

背景

結論：バージョンとcomposer.json

composer.jsonの中身を書き換える

バージョンを合わせる

composerをインストールする

最後に

EC2にLaravelプロジェクトをデプロイしていく中で、artisanが実行できなくなった時にやること

背景

結論：バージョンとcomposer.json

composer.jsonの中身を書き換える

バージョンを合わせる

composerをインストールする

最後に

WordPressの開発環境をDocker(Local)とAWS(Production)で構築手順

Local環境

Docker image の version

開発作業

Local 環境

tree

gitignore

Docker コマンド

本番環境

構成図

Web サーバーを踏み台として DB サーバーに SSH ログインして MySQL をinstall

MySQL コマンド

WordPress をインストール

WordPress とデータベース接続のエラーでハマった点

データベースを使用する権限を付与 part1

データベースを使用する権限を付与 part2

Web サーバーから DB サーバーに通信疎通できない場合

EC2 に git をインストール

Apatch の DocumentRoot を変更する

WordPressの開発環境をDocker(Local)とAWS(Production)で構築

Local環境

Docker image の version

開発作業

Local 環境

tree

gitignore

Docker コマンド

本番環境

構成図

Web サーバーを踏み台として DB サーバーに SSH ログインして MySQL をinstall

MySQL コマンド

WordPress をインストール

WordPress とデータベース接続のエラーでハマった点

データベースを使用する権限を付与 part1

データベースを使用する権限を付与 part2

Web サーバーから DB サーバーに通信疎通できない場合

EC2 に git をインストール

Apatch の DocumentRoot を変更する

WordPress環境をDocker(Local)とAWS(Production)で構築

Local環境

Docker image の version

開発作業

Local 環境

tree

gitignore

Docker コマンド

本番環境

構成図

Web サーバーを踏み台として DB サーバーに SSH ログインして MySQL をinstall

MySQL コマンド

WordPress をインストール

WordPress とデータベース接続のエラーでハマった点

データベースを使用する権限を付与 part1

データベースを使用する権限を付与 part2

Web サーバーから DB サーバーに通信疎通できない場合

EC2 に git をインストール

Apatch の DocumentRoot を変更する

AWS ANS に向けての勉強 2. VPC

AWS ANS に向けての勉強　2. VPC

Gateway型 Private Link型比較

AWS ANS に向けての勉強　1. AWS Direct Connect