AWS（アマゾンウェブサービス）について AWSとは クラウドコンピューティングを使ったクラウドサービスのこと ＜クラウドコンピューティングとは＞ サーバー、データベース、ソフトウェア、ストレージなど、インターネット経由で利用できるクラウドサービスのこと。 WEBサービス、WEBサイトの構築、運用ができる。（Amazon EC2、Amazon Lightsail） データのバックアップ、災害対策。（Amazon S3）。 基幹、業務システムの構築 統合開発環境の構築（Amazon Cloud9） 200以上のサービスをクラウド上で管理できる。 AWSにおけるアカウントとユーザーの違い ❶アカウント→入居場所みたいなもの ❷ユーザー→使う人？ rootユーザーとIAMユーザーの違い rootユーザー↓ AWSアカウント作成時に使用したEメールアドレス、パスワードを使用してサインインすることができるアカウントのこと。 rootユーザーは、アカウントのすべてのAWSサービスとリソースに対して、完全なアクセス権限をもつため、日常のタスクに使用するのは危険。アカウント発行時などの最高権限を必要する操作以外は使用しない。 IAMユーザーとは↓ AWSを利用するアカウントのこと。マネジメントコンソールにログインするためのパスワードとか（らしい）　原則こちらを使用する。 この記事をかいた現段階ではまったくわからないので、徐々に使いながら理解していきたい。

Amazon RekognitionカスタムラベルをCLIとかSDKで使う場合にProject Arnをパラメータとして渡さないといけないんだけど、マネジメントコンソールに書いてない！ 途中まで推測つくんだけど、最後の数値がわからない・・・ arn:aws:rekognition:ap-northeast-1:999999999999:project/#{プロジェクト名}/#{謎の数字・・・} ということで、CLIで調べるしかなさそう describe.sh $ aws rekognition describe-projects { "ProjectDescriptions": [ { "ProjectArn": "arn:aws:rekognition:ap-northeast-1:999999999999:project/rekognition_custom_label_project/9999999999999", "CreationTimestamp": "2021-09-09T09:09:09.090000+09:00", "Status": "CREATED" } ] }

初めてawsの記事を書くので、用語や概念を間違える可能性があります。 社内で開発したAPIを叩いてたまにこう思うのです、 社内のネットワークからアクセスできるAPIのエンドポイントとアクセスできないエンドポイントがある。この違いはなるだろう？ 色々調べたら、これはawsのルーティングテーブルで外部からアクセス可能なsubnetを分けているからです。 例えばこの図のようにリージョンやAZとVPCを立てたとします。ピンクの枠はACL。 （画像はAWS Technical Essentialsコースより） VPCを立てた時にVPC内部のsubnet同士が通信できることを想定されて、デフォルトにMain route tableが作られます。 Destination: 入ってくるIPアドレス(CIDR) Target: そのアクセスをどこにルーティングさせるのか インタネットからのアクセスはgatewayを通してVPCに回します。subnetのinboundでそのアクセスが通るかどうかを決める。 10.1.0.0/16からのアクセスをlocalにルーティングするから他のsubnetにもアクセスできます。 0.0.0.0/0からのアクセスを全てgatewayに回します。（subnetがgatewayを通してネットにアクセスできるようにするため） 開発環境と本番環境のアクセス制御 最初の問題に答えすると、 開発環境のAPIはVPCは社内IPのアクセスを許可し、適切なsubnetに回しました。 本番環境ではその規制が厳しく、同じVPC内のアクセスしか許されてないから社内のネットからでもアクセスできないです。

この記事を書いている私について AWS CloudTechという動画学習サービスに参加し、AWSエンジニアを目指すための備忘録です 本記事の目標 前回の「初めてのCloudFormation 環境準備からVPC作成まで」に引き続き、 今回はAWS CLIkからRDSをスタックを作成します。 まず最初にAWC CLI環境を整えます。 その後、CLIからSSH接続しCloud Formationを使ってプロビジョニングします。 前提条件 ・PCはWindows10が前提。 　Macの方は必要な個所を読み替えていただくようお願いします。 ・下記構成図のようにVPC/EC2（キーペア設定済）/サブネットを作成済みであること。 　　※VPCは前回の記事で作成しているため、再利用します。 　　　下記構成図に記載しているRDSはCloud Formationにて作成します。 今回の構成図 構築の流れ 以下の流れで構築を進めます。 ・コンソールからIAM権限を付与 ・Remote-SSH開発環境を整える ・AWS CLIの設定 ・CloudFormation スタックの作成 ・構築出来たか確認 ・CloudFormation スタックを削除 ・コンソールからIAM権限を付与 ・IAMコンソールを開き、ec2-userを作成します。 　その後、アクセス権限の追加から既存のポリシーをアタッチを選択。 　ポリシーの中からEC2/CloudFormation/VPCの権限をアタッチします。 　※必要な権限だけを割り振るのが良いですが、割り振る権限が分からない方はフルアクセスをアタッチすることになると思います。 　　その場合、学習後は権限を削除しておきましょう。 ・認証情報からアクセスキーの作成を行い、アクセスキーIDとシークレットアクセスキーをメモしておきます。 　※シークレットアクセスキーは一度しか表示されませんので、必ずメモして安全な場所に保管しておいてください。 ・VSCodeのRemote-SSH開発環境を整える 下記の記事を参考にしました。 まず、VSCodeのプラグインRemote - SSHをインストールします。 開発用インスタンス（EC2）を起動し、SSH ログイン設定を行います。 設定後は開発用インスタンスにログインできることを確認します。 ・AWS CLIの設定 ・AWS CLIのインストールを行っていきます。 下記の記事を参考にしました。 ・AWS CLIのconfigファイルを設定していきます。 開発用インスタンス（EC2）にSSH接続を行った後、 ホームディレクトリの下の「.aws」（隠しディレクトリ）にあるテキストファイル 「config」と「credentials」ファイルを作成します。 　①config 　　AWSCLIコマンドの出力形式と操作対象のリージョンを記載する。 　（出力形式は、jsonにする）　 　②credentials 　　IAM権限のアクセスキー、シークレットアクセスキーを記載する。 　　[！！注意！！]絶対に外部に公開しないこと ・CloudFormation スタックの作成 ここからCloudFormationのコマンドを使ってRDSを作成していきます。 ※詳細は他に素晴らしい記事がたくさんありますのでここでは割愛します。 stack.yml AWSTemplateFormatVersion: "2010-09-09" # ------------------------------------------------------------# # Description # ------------------------------------------------------------# Description: CloudTechDemo # ------------------------------------------------------------# # Parameters # ------------------------------------------------------------# #スタック作成時に入力する各種パラメータ Parameters: #データベースパスワード DatabasePassword: Type: String Description: Database password NoEcho: "true" #サブネット ApplicationSubnets: Type: List<AWS::EC2::Subnet::Id> Description: Target subnets #VPCのサイダー VpcId: Type: AWS::EC2::VPC::Id Description: Target VPC #DBinboundのサイダー DBinboundCidrIPs: Type: String Description: SecurityGroupInboundIP # ------------------------------------------------------------# # Resources # ------------------------------------------------------------# #作成する各種AWSリソース Resources: #RDS ApplicationDatabase: Type: AWS::RDS::DBInstance #RDSのプロパティ Properties: Engine: MySQL EngineVersion: 5.7 DBInstanceClass: db.t2.micro AllocatedStorage: 10 StorageType: gp2 MasterUsername: CloudTech MasterUserPassword: Ref: DatabasePassword DBName: CloudTech VPCSecurityGroups: - !Ref ApplicationDatabaseSecurityGroup DBSubnetGroupName: !Ref ApplicationDatabaseSubnetGroup MultiAZ: "false" AvailabilityZone: !Sub ${AWS::Region}a Tags: - Key: Name Value: !Sub ${AWS::StackName}-db #サブネットグループ ApplicationDatabaseSubnetGroup: Type: AWS::RDS::DBSubnetGroup Properties: DBSubnetGroupDescription: Application Database Subnet Group SubnetIds: !Ref ApplicationSubnets Tags: - Key: Name Value: !Sub ${AWS::StackName}-db-subnet-group #セキュリティグループ ApplicationDatabaseSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: !Sub ${AWS::StackName} Application Database Security Group VpcId: !Ref VpcId SecurityGroupIngress: - IpProtocol: tcp FromPort: 3306 ToPort: 3306 CidrIp: !Ref DBinboundCidrIPs Tags: - Key: Name Value: !Sub ${AWS::StackName}-db-sg } dev.cfg DatabasePassword=xxxx ApplicationSubnets=sb-xxxx,sb-xxxx VpcId=xxxx DBinboundCidrIPs=xxxx } ※xxxxの中身はご自身の環境に置き換えて記載してください。 コードの中身について ファイルをstack.ymlとdev.cfgの２つに分けて記述しています。 cfgファイルを分割することで環境毎に違う設定をまとめて管理することが出来ます。 コマンド実行 下記のコマンドで作成したファイルをデプロイします。 aws cloudformation deploy --template-file stack.yml --stack-name RDSmySQLcreate --parameter-overrides $(cat dev.cfg) エラーが無ければ、想定通り構築出来たかコンソール画面を確認していきます。 エラーが発生した場合、下記のメッセージが表示されます。 イベントからエラー内容を確認します。 　※エラーが無い場合は上記のようにステータスがCREATE_COMPLETEとなります。 ・構築出来たか確認 下記の確認をします。 ・コマンド実行後、CloudFormationに画面を切り替えるとRDSmySQLcreate というスタックが作成実行中となってから、下記の確認を行う。 ・RDSのデータベースエンジンは指定したとおりのものになっていること。 ・リージョンはap-northeast-1a、インスタンスタイプはdb.t2.micro、そしてVPCは設定ファイルで指定したVPCで狙いどおりにデプロイされていること。 ・アベイラビリティゾーン/サブネットが想定どおりになっていること。 ・セキュリティグループのインバウンドルールを確認すると、ポート3306で、CIDR IPは設定ファイルで指定したとおりのレンジになっていること。 ・CloudFormation スタックを削除 下記コマンドからRDSはをスタックごと削除します。 aws cloudformation delete-stack 削除したら必ずCloudFormationの画面からも削除されたことを確認してから終了するようにして下さい。 RDSの画面からも作成したRDSが削除中になっていることを確認して下さい。 以上で終了です。お疲れ様でした。 本課題で発生する費用 EC2　X　1 RDS　X　1 一日辺り5円ほどになります。 最後に AWS CLIを使ってCloudFormationを実行する方法が分かりました。 AWS CLI、IAM周りでハマってしまったので、 今後はLinuxやIAM周りを意識して勉強しよう考えています。 AWS CloudTechの課題としてこれらが残っていますので、 やったことを今後のQiita記事にして発信していきたいと思います。 これから始められる方の参考になれば嬉しいです。 今後の学習予定↓↓↓ ・Lamda関数 ・Udemy教材 　AWSで作るWEBアプリケーション 実践講座 　https://www.udemy.com/course/webapplication-on-aws/learn/lecture/22580692#overview ・AWS公式ハンズオン ・社内でAWSハンズオン開催←NEW！！ 　 内容に不備がございましたら、ご指摘いただけますと幸いです。 今後の励みになりますので、良ければ「LGTM」をお願いします。 閲覧ありがとうございました。 この記事はAWS初学者を導く体系的な動画学習サービス「AWS CloudTech」のハンズオンを基に作成しました。

AWSのCodeDeployサービスを使用して、EC2にファイルをデプロイ 現行の環境で、複数ファイルをデプロイする際での手順。 （続けてCodePiplineについても追記） VPC作成(ネットに接続しているVPCが既にあれば飛ばしてOK) VPCダッシュボード＞VPCウィザードを起動＞「パブリックとプライベートサブネットを持つVPC」で選択 IPv4CIDRブロック：10.0.0.0/16 VPC名：わかりやすい任意の名前 パブリックサブネットIPv4CIDR：10.0.0.0/24 パブリックサブネット名：わかりやすい任意の名前 プライベートサブネットIPv4CIDR：10.0.0.1/24 アベイラビリティーゾーン：ap-northeast-1a プライベートサブネット名：わかりやすい任意の名前 Elastic IP 割り当て ID：用意したElasticIPを選択する(別タブでVPC＞Elastic IP＞Elastic IP アドレスの割り当て＞割り当て) IAMロール作成 一つ目作成 IAMダッシュボード＞ロール＞ロールを作成 ユースケースの選択：EC2 ロールの作成：awscodedeployroleを検索して選択 任意のタグと名前(EC2Codedeployroleなど)を付けて作成 二つ目作成 IAMダッシュボード＞ロール＞ロールを作成 ユースケースの選択：EC2 ロールの作成：awscodedeployroleを検索して選択 任意のタグと名前(deploygroupCodedeployroleなど)を付けて作成 *ロール＞作成したロールを選択＞信頼関係のタブ＞信頼関係の編集 ポリシードキュメント内のService項目を以下に書き換える "Service": "codedeploy.ap-northeast-1.amazonaws.com" EC2起動 EC2ダッシュボード＞インスタンスを起動 AMI Amazon Linux 2 インスタンスタイプ t2.micro インスタンスの設定 ネットワークとサブネット：インターネットに接続できるもの 自動割り当てパブリック IP：有効 IAM ロール：今回作成したロール ストレージの追加 デフォルトの汎用SSD タグの追加 わかりやすい任意の名タグ セキュリティグループの設定 セキュリティグループの割り当て：新しいセキュリティグループを作成する セキュリティグループ名:[アプリ名]-sg など 説明：セキュリティグループ名と同じでよい ルールの追加：HTTP 0.0.0.0/0 インスタンスにSSHで接続する *WindowsはTeraTermなどを起動 *つなげたいインスタンスのパブリックIPv4アドレスをコピー *ホスト(T)：[インスタンスのIPv4アドレス] *ユーザー名：ec2-usr *RSA/DSA/ECDSA/ED25519鍵を使う *インスタンスを起動したときにダウンロードしたキーペアを選択 ターミナルの操作 vi install.shでviエディタへ 以下を貼り付けて保存 sudo yum update sudo yum install ruby sudo yum install wget #!/bin/bash CODEDEPLOY_BIN="/opt/codedeploy-agent/bin/codedeploy-agent" $CODEDEPLOY_BIN stop yum erase codedeploy-agent -y cd /home/ec2-user wget https://aws-codedeploy-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/install chmod +x ./install sudo ./install auto 以下コマンドで作成したシェルスクリプトに権限を付与 chmod +x install.sh 権限が付与されていることを確認 ll install.sh シェルスクリプトを実行 ./install.sh LUMPをインストールしておく sudo amazon-linux-extras install -y lamp-mariadb10.2-php7.2 php7.2 sudo yum install -y httpd mariadb-server sudo systemctl start httpd sudo systemctl enable httpd githubの操作 自分のgithub上で新しいリポジトリを作成 gitの操作 gitbashでこちらのAWSのgihubリポジトリのファイルをダウンロードする git clone git clone https://github.com/aws-samples/aws-codedeploy-samples.git *appspec.yml内のsourceを書き換える（以下PHPアプリケーションなどの複数ファイルの場合） version: 0.0 os: linux files: - source: / destination: /var/www/html/ *必要に応じて新しいディレクトリを用意する mkdir ディレクトリ名 cd ディレクトリ名 *ダウンロードしてきたscriptsディレクトリとappspec.yml、デプロイしたいPHPアプリケーションを一つのディレクトリにまとめる *githubリポジトリに上記ディレクトリの中身をpush git init git add . git commit -m "first commit" git branch -M main git remote add origin https://github.com/アカウント名/リポジトリ名.git git push -u origin main AWS CodeDeployの設定 アプリケーションの作成 Codedeployのコンソール＞アプリケーションの作成 アプリケーション名：任意の名前 コンピューティングプラットフォーム：EC2/オンプレミス デプロイグループの作成 アプリケーション名：任意の名前 サービスロール：今回作成したIAMロール名のサービスロールを選択 デプロイタイプ：インプレース 環境設定：Amazon EC2 インスタンス インスタンスに設定したタグを指定する ロードバランサー：有効にするのチェックをはずす そのほかはデフォルトでデプロイグループの作成 デプロイの作成 アプリケーションは GitHub に格納されています　を選択 GitHub トークン名：GitHubアカウント名をで検索し、GitHubアカウントと接続　をクリック リポジトリ名：アカウント/リポジトリ名 コミットID：最新のコミットIDを入力 「成功」が表示されたらデプロイ完了！

今回は日本リックのインフラエンジニア・Hさんに記事をお願いしました。 Hさんは9月に『AWS 認定ソリューションアーキテクト – アソシエイト』に合格したばかり。 今回はSAAの勉強のポイントについて教えてもらいました。 「SAAの”気持ち”」 伝わると嬉しいです。 はじめに こんにちは、今回はエンジニアリンググループ所属のHが担当させていただきます。 普段の業務ではオンプレミスが大半でAWSを扱うことが少ないながら、AWSの資格 ソリューションアーキテクト – アソシエイト(以下SAA) に合格しましたので、私が勉強した上で感じた「SAAの”気持ち”」をこれから資格取得を目指される方向けにお伝えしたいと思います。 ”気持ち”って何？ 初対面の人と仲良くなるにも、事前の情報はあるに越したことはない訳です。 正体不明の相手と探り探り付き合いを始めるのではなく、相手のクセを知ってスムーズに仲良くなって欲しい。 つまり、SAAの 人となり を知って ”コツを掴みやすくなって” 欲しい、という所で ”気持ち” としています。 ”気持ち”を知った後は学習するだけとなりますが、学習方法については数多の記事がWEB上にありますので、そちらを参照されると良いと思います。 自分が疑問に思っていたことを整理した記事になりますので、初心者向けの内容かと思います。 雲を掴むような勉強をしていて難しい。そういった方の参考にもなれば幸いです。 執筆者の技術レベル感 「これは難しい」とか「よくある構成だ」など、どの立ち位置から言っているの？ という事は大事だと思いますので、私のプロフィールを簡単にご紹介します。 ・30代前半 男子 ・CCNA所持 ・オンプレミスが主な業務を2年 ・業務ベースでのAWS構築経験は無し ・個人的なハンズオンでの構築経験は少しだけ有り といった感じになります。 気持ち1：試験ガイドの最後を読む 最初の一歩としてよく紹介されているのが、以下のAWS公式で配布されている 試験ガイドです。 「試験ガイドを読んで求められている事を把握しましょう」というアドバイスを目にしますので、勉強し始めの頃にガイドを途中まで見てみましたが、正直なところ 『世の人はこの文言で試験に内容を把握できるのか！？』 と自分に対して残念な気持ちになりました。 求められている事が言語化されていて、ありがたいと言えばありがたいのですが、それを学びに活かせるかどうかは別問題かと･･･。なので、そちらはまた今度読むことにしまして、直接活かせる情報を得ましょう。 試験ガイドですぐに活かせる分かりやすい情報は一番最後の付録となります。 付録には試験の対象となるサービスが列挙されています。 AWSのサービスを調べると分かりますが、200を超えるサービスが有ります。その中で何について勉強すればいいかを把握することが第一歩でしょう。 できれば一覧に乗っているサービスで何が出来るかを、ざっくり理解しておくと勉強がはかどると思います。 気持ち2：そもそもソリューションアーキテクトって何？ 資格の対象となるサービス群は理解できたかと思いますが、それらについてどのように理解すればいいの？という点については、方向性が定まっていないのではないでしょうか。 さて、SAAはソリューションアーキテクトの資格ですので、ソリューションアーキテクト的な目線でサービスを理解すればSAAの試験をクリアできるわけです。 私の解釈では「ソリューションアーキテクト」＝「適切なサービス構成(ソリューション)を提案できる人」と理解しています。 つまり 「やりたい事はこのサービスで出来ますね」 「A,Bどちらのサービスでも希望は達成できますが、Aの方が安くて早くて上手いでしょう」 「そのサービスを使用する際はこのサービスと連携するのがベストですよ」 「サービス同士はこれで接続しましょう」 「構成の提案はできますが、詳細な構築手順や運用上の懸念についてはそれほど知りません」 と言える人物になる事です。 気持ち1の試験ガイドに乗っているサービスについて上記のような事が言えるように、サービスを理解出来るようになることが大切です。 気持ち3：前提条件と接続する方法が大事 AWSといえばEC2、S3が代名詞となっている程に有名ですが、実際に使用するには、どうやってこの二つのサービスを作成して接続するでしょうか？？ ざっくり表現するとこんな感じです。 [作成] VPC作成 → サブネット作成 → EC2作成 S3バケットの作成 [接続] VPCエンドポイントを作成してVPCとS3をつなぐ このようにEC2を建てるためにはVPCをまず作成していなければいけません。構築時に前提条件を忘れていてエラーで怒られるという事はよくあるので、勉強される時は１，２，３，と順番を振って前後関係をハッキリさせると、サービス全体の理解も実際の構築にも役立つ事請け合いです。(多分) 実際は上記例にプラスしてもう少し必要なものが有りますが、そういった所を理解するためにEC2ぐらいであれば作成してみると良いと思います。 また通常のネットワークがそうであるように、AWSでもデータの移動経路として入口と出口が出来ますが、サービスによって接続可能な接続元と接続先があります。 ・どのサービス"で"接続できるか ・どのサービス"へ"接続できるか ここを意識できれば、様々な資料から得られる気づきポイントも多くなります。 気持ち4：要件の単語とサービスを結びつける 受験にあたってのテクニックにもなりますが、解決したい内容を単語で捉えて、その単語とサービスと結び付けられるようになれば、理解しやすくなります。 こちらも例を出してみます。 TB単位のデータ、BIツール　⇒Redshift 静的WEBサービス、低い運用コスト　⇒CloudFrontとS3 疎結合、サーバレス、不定期な処理、15分以内の処理　 　⇒SQSとLmbda 　　　　サーバレス、不定期な処理、15分を超える可能性 ⇒S3とglue や Batch AWSでの構築事例やWEB上の記事で「今回は〇〇を▽▽するために☆☆を使ってみました」という文があった時には 〇〇、▽▽　⇒☆☆ といった形で結び付ければサービス毎の差異が分かりやすいです。 上記例でもLmbdaを使うかどうかの基準が一例ではありますが、分かりやすいと思います。 構築例はガチガチの暗記ではなくストーリーチックだったりするので、意外と記憶に残るかもしれません。 まとめ いかがでしょうか、SAAさんの ”人となり” は掴めたでしょうか？ SAAは「AWSという新しい商品」についての知識を問われる資格なので、これまでどれだけオンプレミスでのインフラ歴が有ろうとも、勉強無しで取れる資格ではないと思います。 新人もベテランも、どれだけAWSを使用して勉強したかが試されていることになります。 つまり、AWSの前にはみな平等ということです！(過言です) 理解の応用力に差はあれど、一からの勉強であることに変わりは無いので、皆さんも同じ道のりを越えて頂ければと思います。 付録 一番大事なのは一番最後の付録ですので、私が勉強になったページをご紹介します。 多くの人が躓くのでおなじみの IAM について解説されているページです。 このページを見れば IAM嫌い が無くなる事間違いなしです。(過言ではない)

DataKeeperとは サイオステクノロジー株式会社が提供しているストレージのミラーリングソフトです。 DataKeeperを使用することでクラスタノード間でストレージをミラーリングして共有ストレージのように扱うことが可能になります。 クラスタリングソフトのLifeKeeper又はWindowsのWSFCとも連携することができます。 作業環境 今回の作業は下記の環境で実施しました。 サーバ：AWS EC2 x 2台 (稼働系と待機系) OS：RedHatEnterpriseLinux 7.7 クラスタリングソフト：LifeKeeper for Linux v9.5.0 (DataKeeper含む) 尚、AWSでのEC2構築やLifeKeeper・DataKeeperのインストール・設定に関しては本記事では記載しておりません。 LifeKeeperのクラスタリソースもDataKeeperによるミラーディスクのみのシンプルな構成で作業を行っています。 作業手順 ①拡張対象のディスクデバイス名の確認 LifeKeeperのコマンドを使用して稼働系と待機系でミラーリングディスクのデバイス名を確認します。 # lcdstatus ※以下ミラーリングに関する表示のみ抜粋 datarep-mnttest: id=c464694d-8d44-4927-b60b-0a7427ff7049 app=scsi type=netraid state=ISP initialize=(AUTORES_ISP) automatic restore to IN-SERVICE by LifeKeeper info=0/dev/nvme1n1p110.0.2.2020969472gpt0/opt/LifeKeeper/bitmap__mnttest256M reason=restore action has succeeded these resources are dependent: /mnttest Local priority = 1 SHARED equivalency with "datarep-mnttest" on "lk-sby", priority = 10 FAILOVER ALLOWED この例ではコマンドの出力結果の3行目に表示されている「/dev/nvme1n1p1」がミラーリングディスクのデバイス名となります。 AWS EC2の場合はこのデバイス名がOS再起動のタイミング等で変わる可能性があるため、必ず事前にデバイス名を確認することをお勧めします。 ②ディスクデバイス名に対応するEBS VolumeIDの確認 AWS側の操作でディスク(EBS)を拡張するためにnvmeコマンドを使用して対象のデバイス名に対応するEBS VolumeIDを確認します。 # nvme id-ctrl -v /dev/nvme1n1p1 NVME Identify Controller: vid : 0x1d0f ssvid : 0x1d0f sn : vol07d46259abcccf227 mn : Amazon Elastic Block Store fr : 1.0 rab : 32 ieee : a002dc ～以下省略～ 「sn」の行のvolから始まる文字列がEBS VolumeIDです。 稼働系、待機系でそれぞれIDが異なるため両方で確認します。 ③ディスクサイズの拡張 AWS側でディスク(EBS)の拡張を行います。 まずは拡張前のディスクサイズを確認します。 「--volume-ids」オプションの引数には「②ディスクデバイス名に対応するEBS VolumeIDの確認」で確認したVolumeIDを指定します。 # aws ec2 describe-volumes --volume-ids vol-07d46259abcccf227 { "Volumes": [ { "Attachments": [ { "AttachTime": "2021-10-13T08:20:57+00:00", "Device": "/dev/sdf", "InstanceId": "i-0xx78bxx85dfxx0e0", "State": "attached", "VolumeId": "vol-07d46259abcccf227", "DeleteOnTermination": false } ], "AvailabilityZone": "ap-northeast-1a", "CreateTime": "2021-10-13T08:20:37.496000+00:00", "Encrypted": false, "Size": 20, "SnapshotId": "", "State": "in-use", "VolumeId": "vol-07d46259abcccf227", "Iops": 3000, ～以下省略～ 「"Size": 20」と表示されており現在のディスクサイズは20GiBであることが確認できます。 このディスクサイズを20GiB→50GiBに拡張します。 # aws ec2 modify-volume --volume-id vol-07d46259abcccf227 --size 50 { "VolumeModification": { "VolumeId": "vol-07d46259abcccf227", "ModificationState": "modifying", "TargetSize": 50, "TargetIops": 3000, "TargetVolumeType": "gp3", "TargetThroughput": 125, "TargetMultiAttachEnabled": false, "OriginalSize": 20, "OriginalIops": 3000, "OriginalVolumeType": "gp3", "OriginalThroughput": 125, "OriginalMultiAttachEnabled": false, "Progress": 0, "StartTime": "2021-10-14T10:00:03+00:00" } } 再度ディスクサイズを確認します。 # aws ec2 describe-volumes --volume-ids vol-07d46259abcccf227 { "Volumes": [ { "Attachments": [ { "AttachTime": "2021-10-13T08:20:57+00:00", "Device": "/dev/sdf", "InstanceId": "i-0xx78bxx85dfxx0e0", "State": "attached", "VolumeId": "vol-07d46259abcccf227", "DeleteOnTermination": false } ], "AvailabilityZone": "ap-northeast-1a", "CreateTime": "2021-10-13T08:20:37.496000+00:00", "Encrypted": false, "Size": 50, "SnapshotId": "", "State": "in-use", "VolumeId": "vol-07d46259abcccf227", "Iops": 3000, ～以下省略～ 「"Size": 50」と表示されておりディスクが50GiBに拡張されたことが確認できます。 この作業を稼働系、待機系の両方で実施します。 ④パーティションの拡張 ディスクの拡張が完了したので次にOS側のパーティションの拡張を実施します。 まずは拡張前の状態を確認します。 # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nbd1 43:1 0 20G 0 disk mqmd0 9:0 0 20G 0 raid1 /mnttest nvme0n1 259:2 0 10G 0 disk ┗nvme0n1p1 259:3 0 1M 0 part ┗nvme0n1p2 259:4 0 10G 0 part / nvme1n1 259:0 0 50G 0 disk ┗nvme1n1p1 259:1 0 20G 0 part 　┗md0 9:0 0 20G 0 raid1 /mnttest コマンド出力結果の下から3行目に表示されているのが「③ディスクサイズの拡張」で拡張したディスク(EBS)の/dev/nvme1n1を示しており、サイズが拡張後の50GBとなっています。 但しその下に表示されているパーティション/dev/nvme1n1p1のサイズはまだ20GBです。 partedコマンドで対話形式でパーティションを拡張します。 # parted /dev/nvme1n1 GNU Parted 3.1 Using /dev/nvme1n1 Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p　　　※p を入力 Error: The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the disk is smaller. Fix, by moving the backup to the end (and removing the old backup)? Fix/Ignore/Cancel? Fix　　　※これが表示された場合は Fix を入力 Warning: Not all of the space available to /dev/nvme1n1 appears to be used, you can fix the GPT to use all of the space (an extra 62914560 blocks) or continue with the current setting? Fix/Ignore? Fix　　　※これが表示された場合は Fix を入力 Model: NVMe Device (nvme) Disk /dev/nvme1n1: 53.7GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 21.5GB 21.5GB xfs 1 (parted) resizepart 1 100%　　　※パーティションサイズをディスク容量の100%まで拡張 (parted) p　　　※p を入力 Model: NVMe Device (nvme) Disk /dev/nvme1n1: 53.7GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 53.7GB 53.7GB xfs 1　　　　　　※パーティションサイズが拡張された (parted) q　　　※q を入力してpartedコマンドを終了 Information: You may need to update /etc/fstab. 改めてlsblkコマンドでパーティションが拡張されたことを確認します。 # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nbd1 43:1 0 20G 0 disk mqmd0 9:0 0 20G 0 raid1 /mnttest nvme0n1 259:2 0 10G 0 disk ┗nvme0n1p1 259:3 0 1M 0 part ┗nvme0n1p2 259:4 0 10G 0 part / nvme1n1 259:0 0 50G 0 disk ┗nvme1n1p1 259:1 0 50G 0 part 　┗md0 9:0 0 20G 0 raid1 /mnttest この作業も稼働系、待機系の両方で実施します。 ⑤ミラーサイズの変更 稼働系でミラーサイズの変更を実施します。 mirror_resizeコマンドの引数に拡張対象のミラーディスクのリソースタグ名を指定します。 リソースタグ名はlcdstatusコマンドで確認可能です。 ※リソースタグ名を確認 # lcdstatus -e BACKUP TAG ID STATE PRIO PRIMARY lk-sby /mnttest /mnttest ISP 1 lk-act lk-sby datarep-mnttest c464694d-8d44-4927-b60b-0a7427ff7049 ISP 1 lk-act MACHINE NETWORK ADDRESSES/DEVICE STATE PRIO lk-sby TCP 10.0.0.10/10.0.0.20 ALIVE 1 lk-sby TCP 10.0.2.10/10.0.2.20 ALIVE 2 ※ミラーサイズの変更 # mirror_resize datarep-mnttest Resize mirror datarep-mnttest (/dev/md0) from 20.0 GB to 50.0 GB ? WARNING: This will cause a full resynchronization. Are you sure (y/n) ? y　　　※y を入力 The mirror datarep-mnttest will now be resized from 20969472 KB (20.0 GB) to 52427759 KB (50.0 GB). Pausing mirror datarep-mnttest: lk-act -> lk-sby... The mirror to lk-sby has been paused Temporary read/write access for datarep-mnttest set up on the mount point "/mnttest" on server lk-sby. You must access the data from this mount point ONLY! All changes made to the data on server "lk-sby" via the mount point "/mnttest" will be DISCARDED when the mirror is resumed. /opt/LifeKeeper/lkadm/subsys/scsi/netraid/bin/mdadm --grow /dev/md0 --bitmap=none /opt/LifeKeeper/lkadm/subsys/scsi/netraid/bin/mdadm --grow /dev/md0 --size=52427759 mdadm: component size of /dev/md0 has been set to 52427759K Resizing bitmap on lk-sby lcdremexec -d lk-sby -e -- bitmap -x 52427759 /opt/LifeKeeper/bitmap__mnttest Extending bitmap by 15361 bytes Resizing bitmap on lk-act lcdremexec -d lk-act -e -- bitmap -x 52427759 /opt/LifeKeeper/bitmap__mnttest Extending bitmap by 15361 bytes /opt/LifeKeeper/lkadm/subsys/scsi/netraid/bin/mdadm --grow /dev/md0 --bitmap=/opt/LifeKeeper/bitmap__mnttest --bitmap-chunk=256 --force assume non-persistent superblock : No such file or directory Forcing full resync... Resuming mirror datarep-mnttest: lk-act -> lk-sby... sh: exportfs: command not found mdadm: stopped /dev/md0 Set full resync to target lk-sby. Full resynchronization of component "/dev/nbd1" has begun for mirror "/dev/md0" The mirror to lk-sby has been resumed The mirror datarep-mnttest has been resized from 20969472 KB (20.0 GB) to 52427759 KB (50.0 GB). ミラーサイズの変更を実行するとディスクの全同期が開始されます。 同期完了までの時間はネットワークレイテンシやディスクサイズに依存するため、クラスタノードがAWSのAZやRegionを跨いでいたりディスクが大容量の場合は同期完了までに時間を要しますので御注意下さい。 同期の状態はコマンドで確認できます。 # mirror_status datarep-mnttest Mirror Configuration: [-] lk-act -> lk-sby (10.0.2.20) Status: Resynchronizing [=========> ] 54% Resync Speed: 59200K/sec Type: Synchronous Bitmap: 204796 bits (chunks), 0 dirty (0.0%) # cat /proc/mdstat Personalities : [raid1] md0 : active raid1 nbd1[2](W) nvme1n1p1[0] 52427759 blocks super non-persistent [2/1] [U_] [===========>.........] recovery = 57.7% (30260096/52427759) finish=6.2min speed=58805K/sec bitmap: 0/100 pages [0KB], 256KB chunk, file: /opt/LifeKeeper/bitmap__mnttest unused devices: <none> ⑥ファイルシステムの拡張 最後にOSのファイルシステムを稼働系で拡張します。 今回の環境ではXFSファイルシステムを使用してるため拡張にはxfs_growfsコマンドを使用します。 拡張前のファイルシステム(/dev/md0)は20GBとなっています。 # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 1.8G 0 1.8G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 9.0M 1.9G 1% /run tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/nvme0n1p2 10G 4.0G 6.0G 40% / tmpfs 373M 0 373M 0% /run/user/1000 /dev/md0 20G 33M 20G 1% /mnttest ファイルシステム(/dev/md0)を拡張します。 xfs_growfs /dev/md0 meta-data=/dev/md0 isize=512 agcount=4, agsize=1310592 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=0 spinodes=0 data = bsize=4096 blocks=5242368, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 data blocks changed from 5242368 to 13106939 ファイルシステム(/dev/md0)が50GBに拡張されました。 df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 1.8G 0 1.8G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 9.0M 1.9G 1% /run tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/nvme0n1p2 10G 4.0G 6.0G 40% / tmpfs 373M 0 373M 0% /run/user/1000 /dev/md0 50G 33M 50G 1% /mnttest 以上で拡張作業は完了です。 作業中に別ターミナルで拡張領域へ常時ファイルの書き込みを行っていましたが特にエラー等は発生しなかったためオンラインでの拡張が正常に行われたと判断できます。 また、待機系でもリソースを起動してみましたが拡張後のサイズでファイルシステムが認識されていることを確認しました。 尚、オンライン拡張は可能ですが拡張中は対象領域のI/O負荷が高くなるため実施するタイミングについては考慮が必要となります。 参考リンク

はじめに ある日、画像のような状態になり、急にオリジナルアプリに接続できなくなりました。 結果単純な事だったのにも関わらず、解決までとても時間がかかったので記録に残します。 解決方法 お名前.comでの認証不足で機能を制限させたれていただけでした。 デプロイして、「さあ画面を見てみよう！」ってタイミングで出たので、AWSでの設定と思い込みすごく迷いました。 【確認手順】 1. お名前.comにログイン 2. ドメインの詳細 3. ステータス を確認して下さい。何かコメントされていませんか？ 私の場合は、 「登録した際に送信したメール認証作業が完了していないよ！だから機能制限中やで！」 って表示されてました。 丁寧に対応方法を表示してくれてあるので、すぐに対応できました。 さいごに 私の場合、ドメイン取得時に間違ったメールアドレスで登録してしまったという事があったので発生した事だと思います。 DNS_PROBE_FINISHED_NXDOMAIN　について調べていると他にも原因があったりするみたいなので、気をつけて下さい。 参考文献 異常時に読み返していた文献です。ドメイン取得やSSL化などの際にお世話になりました。 - 【ドメイン取得】お名前.comとawsでドメイン取得 - AWSでSSL化する方法を伝授！！！ - サルでもできる!? Rails6 のアプリをAWS EC2にデプロイするまでの全手順【前半】（VPC, RDS, EC2, Capistrano） - サルでもできる!? Rails6 のアプリをAWS EC2にデプロイするまでの全手順【後半】（独自ドメイン, HTTPS化, S3, CloudFront）

はじめに 本記事はCloud Center of Excellence（以下、CCoE）について、CCoE立ち上げに関する視点から基本的な考え方について記載しています。 クラウドファーストという言葉が意味する通りに、クラウドインフラの利用はITサービスを実現するための手段として第一に考えるべき戦略の一つです。 近年、パブリッククラウドのサービスを提供するクラウド事業者は、クラウド活用に有効な手段としてCCoEという役割に着目し、その重要性を謳っています。 ※本記事の内容は、あくまで考え方の一例であり、必ずしも全ての考え方がシステムに適合したり、ここに書いている内容で満たされている訳ではありません。 CCoE CCoEは、CloudとCenter Of Excellence（以下、CoE）を組み合わせた造語です。 CoEという単語はビジネス用語として、ITに関わらず様々な業界、行政、研究所などで使用されてきました。 業界や組織によって役割は異なりますが、組織の中間拠点や、横断組織等ハブ的機関を意味します。 すなわち、組織の中核となる専門分野の集団として位置づけられていることが多く、IT業界ではCloudの推進組織としてCCoEという言葉が使われています。 CCoEの導入目的 CCoEは役割ではなく、DevOpsの様に文化に近い概念だと考えています。 何故ならば、導入する組織やポジションによって視座が異なるため、CCoEに求められる役割や考え方は変わってくるからです。 CCoEを組織に導入して正しく機能させるためには、以下に示す様な組織的な課題に対して、CCoEの導入目的を正しく設定することが重要だと考えています。 クラウド戦略 ガバナンス また、導入したら終わりではなく、運用開始後SLAやコストなど定量的に分析できる指標をKPIとし、継続的にビジネスを支えていくことが重要だと思います。 クラウド戦略 ビジネスの基本的原則である戦略は元々、軍事用語からきています。 「戦略なくして戦術なし」と言われる様に、戦略ありきでクラウドを目的ではなく、目的を達成するための手段として考えます。 Why? Do you use AWS? ITサービスをローンチするために、クラウドインフラとしてAWSを利用する組織は多いと思います。 「何故、AWSを利用するのか？」 ビジネス要件を理解した上で、コストや機能等何らかの軸を持って、クラウドの選定理由を持つことが重要です。 また、ビジネスに影響を与える意思決定については、必ず経営層と合意を取ることも必要不可欠です。 パブリッククラウド・プライベートクラウド ビジネスでコストを重要視するのであれば、プライベートクラウドの構築も一つの戦略です。 OpenStackを利用することで独自のプライベートクラウド環境を構築することができます。 しかし、将来的なコスト削減の効果は大きいと思いますが、構築するための導入コストや、運用コストが大きいため、現実的に導入するのは総合的に難易度が高いのが現状です。 理由として、何らかの問題が発生してもオープンソースソフトウェア（OSS）のため、パブリッククラウドと比較すると、サポートなどの保証は充実しておりません。また、AWSなどと比べると採用面に対するハードルへの影響も大きいと思われるため、小規模で流動的な組織の場合、導入は難しいと思われます。 責任共有モデル クラウドを利用するために責任共有モデルの理解は必要です。 また、SIerなどITベンダーの場合、顧客にも説明を行い、理解させることが望ましいです。 責任共有モデルはシステムに対する自由度や、コストなどトレードオフの性質を持っています。 例としてAWSでDBサーバを構築する際に、EC2を選択する場合はRDSと比べて、自由度が高く料金は安くなりますが、運用コストは高くなります。 端的に言うとレイヤーに対する責任分解、セキリュティの観点からデータ保護など遵守すべき法令やガイドライン等、検討しないといけないことはたくさんあります。 AWSの場合は以下資料が参考になります。 AWS ホワイトペーパーとガイド AWS コンプライアンスプログラム 特に、セキュリティという観点ではクラウドを提供する側と、利用者側での相互理解が重要です。 責任共有モデルの概念を正しく理解してシステムを作り込むことで、野球で言うポテンヒットを防ぎ、システムを健全な状態に近づけることができるでしょう。 ガバナンス ガバナンスはビジネス用語として、企業統治の意味合いで使用されていることが多く、主にガバナンス強化というフレーズで使用されることが多いと思います。 ビジネス上のガバナンス強化に伴い、ITサービスの開発・運用プロセスへの影響度は大きいため、ただルールを作ったら終わりではなく、効果的に機能させるための仕組み作りが重要です。 ガイドライン パブリッククラウドを利用して、SaaS型ビジネスモデルを構築し、ITサービスを展開する事業者は今後も増えていくと思いますが、クラウドの利用にはまだまだ課題があります。 従来、オンプレミスのシステムにおいてインフラを構築する際のフレームワークは非機能要求グレードが利用されてきました。 「非機能要求グレード」は、「非機能要求」についてのユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的とし、非機能要求項目を網羅的にリストアップして分類するとともに、それぞれの要求レベルを段階的に示したものです。重要な項目から順に要求レベルを設定しながら、両者で非機能要求の確認を行うことができるツール群です。 クラウドファーストの今、パブリッククラウドを利用してITサービスを構築する際に、非機能要求グレードの様な認知度があり汎用的なツールが存在しないため、サービスや組織の成長に伴い、ガバナンス強化のフェーズでクラウドの運用課題が顕在化する組織が多いのではないかと思います。 従って、ITサービス構築時にクラウドインフラの設計技法に関するフレームワークを利用することで、運用フェーズでのコストを下げることができると考えています。 例えば、情報セキュリティ対策の指針としては以下に示す、総務省が公開しているガイドラインの活用が効果的ではないかと思います。 「クラウドサービス提供における情報セキュリティ対策ガイドライン（第3版）」（案）に対する意見募集の結果及び「クラウドサービス提供における情報セキュリティ対策ガイドライン（第3版）」の公表 この総務省の公開している資料は、JIS Q 27000などを基に、ガイドラインを策定しているため、日本の国家規格に準拠していることになります。 従って、この様なガイドラインに準拠することで国が求める基準を満たし、システムの品質や安全性を表現することができます。 なお、AWSの場合、AWS Well-Architectedを利用することでAWSにおけるアーキテクチャのベストプラクティスを使ったインフラの構築ができます。 AWS Well-Architected フレームワークは、以下5本の柱を基本としています。 運⽤性 セキュリティ 信頼性 パフォーマンス効率 コスト最適化 詳細についてはAWS Well-Architected フレームワークのドキュメントを参照。 また、現在はホワイトペーパーとして公開されていたものがAWS Well-Architected Toolにサービス化されているので、ベストプラクティスについて導入しやすい仕組みになっています。 利用方法についてはAWSコンソール画面からワークロードを作成し、レビューを行う項目にチェックを入れてレビューを行う作りになっています。レビュー完了後、ワークロードに対するリスクが表示されます。 内部統制 内部統制はITサービスの開発・運用プロセスに対して大きく影響します。 例えば運用ルールを策定していない場合、何らかの開発で構築したサーバリソースなどが残り続けて、全く使用していないのに毎月課金され続けるというのはよくある話です。 クラウドリソースを利用するための運用ルールを策定することで、無駄な支出を防ぐことができます。 スタートアップなど人の流動性が高い組織で多いと思いますが、後から使用していないリソースを削除するにしても、消して大丈夫かなどの確認作業が発生し、時間が経過すればするほど対応に手間がかかります。 また、クラウドリソースなどを変更した場合、作業や変更に関わる履歴を残すことで運用を円滑にします。 具体的には以下の様な誰が、何のために、何を、どうやって変更したか等の情報があると良いと思います。 Who? Why? What? How？ AWSの場合、以下のサービスがあります。 AWS CloudTrail AWS Config Amazon GuardDuty AWS Security Hub AWS CloudTrailを利用することで、ユーザーのアクティビティをAPIレベルでトラッキングして証跡管理を行うことができます。また、AWS Configでは設定変更の履歴を管理できます。 そして、Amazon GuardDutyや、AWS Security Hubを組み合わせて、システム上に存在する脆弱性に対する脅威を検出し、リスクを低減することができます。 おわりに トイレットペーパーのサイズは日本のJIS規格によって標準化されていて、114mmと決められています。そのため、どこのメーカーの商品を買っても備え付けのホルダーに取りつけることができます。 システム的に言うと、例えばLinuxの場合、Filesystem Hierarchy Standardと言う概念があります。 クラウドインフラの場合、CCoEを軸にして普遍的かつ、不変的にシステムを作り込むことがこれから求められるスキルではないかと思いました。 参考 AWS Create a Cloud Center of Excellence AWS Cloud Enterprise Strategy Blog Tag: CCOE Azure クラウドのセンター オブ エクセレンス (CCoE) 機能 Cloud center of excellence (CCoE) functions GCP Google Cloud Japan が CCoE（Cloud Center of Excellence）研究分科会を発足 CCoE 研究分科会

以前、GitHubへのPush時にAWS CodeCommitにリポジトリを同期する方法をまとめました。 しかし、この方法はリポジトリをまるまるミラーリングするため、特定のブランチのみ同期したいという場合は使えません。 今回、GitHubの任意のブランチをCodeCommitの任意のブランチにGitHub Actionsから同期する方法を検討したためメモしておきます。 GitHubのSecretsに必要な情報を登録 GitHubの管理画面で、「Settings」 -> 「Secrets」から、必要な情報を登録します。 登録する情報は下記となります。 CODECOMMIT_REPO_URL CodeCommitのリポジトリのURL CODECOMMIT_SSH_CONFIG SSH接続するためのコンフィグ情報 Host git-codecommit.*.amazonaws.com User {CodeCommitのSSHキーID} IdentityFile ~/.ssh/id_rsa StrictHostKeyChecking no CODECOMMIT_SSH_PRIVATE_KEY SSHシークレットキー GitHub Actionsを設定 下記のコードを、GitHub Actionsのワークフローとして登録します。 name: "Deploy: main" on: [ workflow_dispatch ] jobs: build: runs-on: ubuntu-latest timeout-minutes: 5 steps: - name: Checkout uses: actions/checkout@v2 with: fetch-depth: 0 - name: Extract branch name shell: bash run: echo "::set-output name=branch::${GITHUB_REF#refs/heads/}" id: extract_branch - name: Push to AWS CodeCommit env: CODECOMMIT_HOST: git-codecommit.ap-northeast-1.amazonaws.com # ap-northeast-1の部分は自身のリージョンを指定 CODECOMMIT_REPO_URL: ${{ secrets.CODECOMMIT_REPO_URL }} CODECOMMIT_SSH_CONFIG: ${{ secrets.CODECOMMIT_SSH_CONFIG }} CODECOMMIT_SSH_PRIVATE_KEY: ${{ secrets.CODECOMMIT_SSH_PRIVATE_KEY }} BRANCH_NAME: ${{ steps.extract_branch.outputs.branch }} shell: bash run: | mkdir ~/.ssh echo "$CODECOMMIT_SSH_PRIVATE_KEY" > ~/.ssh/id_rsa && chmod 600 ~/.ssh/id_rsa echo "$CODECOMMIT_SSH_CONFIG" > ~/.ssh/config && chmod 600 ~/.ssh/config ssh-keyscan "$CODECOMMIT_HOST" >> ~/.ssh/known_hosts && chmod 600 ~/.ssh/known_hosts git remote add codecommit "$CODECOMMIT_REPO_URL" git push codecommit ${{ env.BRANCH_NAME }}:main -f # mainの部分はCodeCommitの同期したいブランチを指定 GitHub Actionsから同期を実行 GitHub Actionsから、CodeCommitに同期したいブランチを選択して「Run workflow」を実行することで、任意のブランチをCodeCommitのmainブランチにpushできます。 ワークフローの、CodeCommitの同期したいブランチを変更することで、任意のブランチと同期可能になります。

以前、GitHubへのPush時にAWS CodeCommitにリポジトリを同期する方法をまとめました。 しかし、この方法はリポジトリをまるまるミラーリングするため、特定のブランチのみ同期したいという場合は使えません。 今回、GitHubの任意のブランチをCodeCommitの任意のブランチにGitHub Actionsから同期する方法を検討したためメモしておきます。 GitHubのSecretsに必要な情報を登録 GitHubの管理画面で、「Settings」 -> 「Secrets」から、必要な情報を登録します。 登録する情報は下記となります。 CODECOMMIT_REPO_URL CodeCommitのリポジトリのURL CODECOMMIT_SSH_CONFIG SSH接続するためのコンフィグ情報 Host git-codecommit.*.amazonaws.com User {CodeCommitのSSHキーID} IdentityFile ~/.ssh/id_rsa StrictHostKeyChecking no CODECOMMIT_SSH_PRIVATE_KEY SSHシークレットキー GitHub Actionsを設定 下記のコードを、GitHub Actionsのワークフローとして登録します。 name: "Deploy: main" on: [ workflow_dispatch ] jobs: build: runs-on: ubuntu-latest timeout-minutes: 5 steps: - name: Checkout uses: actions/checkout@v2 with: fetch-depth: 0 - name: Extract branch name shell: bash run: echo "::set-output name=branch::${GITHUB_REF#refs/heads/}" id: extract_branch - name: Push to AWS CodeCommit env: CODECOMMIT_HOST: git-codecommit.ap-northeast-1.amazonaws.com # ap-northeast-1の部分は自身のリージョンを指定 CODECOMMIT_REPO_URL: ${{ secrets.CODECOMMIT_REPO_URL }} CODECOMMIT_SSH_CONFIG: ${{ secrets.CODECOMMIT_SSH_CONFIG }} CODECOMMIT_SSH_PRIVATE_KEY: ${{ secrets.CODECOMMIT_SSH_PRIVATE_KEY }} BRANCH_NAME: ${{ steps.extract_branch.outputs.branch }} shell: bash run: | mkdir ~/.ssh echo "$CODECOMMIT_SSH_PRIVATE_KEY" > ~/.ssh/id_rsa && chmod 600 ~/.ssh/id_rsa echo "$CODECOMMIT_SSH_CONFIG" > ~/.ssh/config && chmod 600 ~/.ssh/config ssh-keyscan "$CODECOMMIT_HOST" >> ~/.ssh/known_hosts && chmod 600 ~/.ssh/known_hosts git remote add codecommit "$CODECOMMIT_REPO_URL" git push codecommit ${{ env.BRANCH_NAME }}:main -f # mainの部分はCodeCommitの同期したいブランチを指定 GitHub Actionsから同期を実行 GitHub Actionsから、CodeCommitに同期したいブランチを選択して「Run workflow」を実行することで、任意のブランチをCodeCommitのmainブランチにpushできます。 ワークフローの、CodeCommitの同期したいブランチを変更することで、任意のブランチと同期可能になります。

前提 ・Docker使える状態 ・AWSサービス使える状態 ①amazon linuxのイメージを取得 docker pull amazonlinux ②Dockerfileを作成 FROM amazonlinux:latest RUN yum install -y python3 zip RUN mkdir /home/deploy ③docker-compose.ymlを作成 docker-compose.yml version: '2' services: app: build: . volumes: - './deploy:/home/deploy' command: > bash -c "pip3 install -r /home/deploy/requirements.txt -t /home/deploy/python && cd /home/deploy && /usr/bin/zip -r bs4.zip python" ④ディレクトリを作成 今回は、Dockerfileとymlに記載したディレクトリ名と合わせてdeployというディレクトリと、その下にこちらは決め打ちのpythonというディレクトリを作成します。 ⑤pip installするライブラリを記述したrequirement.txtを作成しdeployディレクトリ配下に置く。 今回はwebスクレイピングで使うbs4とrequestsを記述します。まずはbs4のみ。 requirements.text bs4 ⑥ディレクトリ構成の確認 $ tree ├── Dockerfile ├── deploy │ ├── python │ └── requirements.txt └── docker-compose.yml ⑦Lambdaレイヤーにアップロードするパッケージを取得 下記をコマンド実行します。 docker-compose up --build ⑧もう一つのパッケージを作るために③と⑤を編集し⑦を実行(必要なパッケージが一つだけなら不要) docker-compose.yml version: '2' services: app: build: . volumes: - './deploy:/home/deploy' command: > bash -c "pip3 install -r /home/deploy/requirements.txt -t /home/deploy/python && cd /home/deploy && /usr/bin/zip -r requests.zip python" requirements.text requests docker-compose up --build ⑨レイヤーの作成 ⑧までに作成したパッケージをアップロードします。 ※ランタイムは3.7以下にします。3.8以上はamazonlinux2でないといけないので本記事の対象外です。 ⑩レイヤーの追加 先ほどの⑨で作ったレイヤーを動かしたいLambda関数に追加します。 種類はカスタムレイヤーで選択します。 ⑪Lambdaを動かしてみる まずはレイヤーを作らなかった時の失敗例をご覧ください。bs4やrequestsは元々Lambdaに用意されていないのでエラーになります。 続きましてレイヤーを追加した成功例です。今回はライブラリがimportできているので、目的の口コミスクレイピングが出来ています。

iOS15のリリースに合わせてiCloudがiCloud+にアップグレードしました。 その中で「カスタムメールドメイン」という機能が気になったので設定してみました。 最大で５ドメインの３アドレス、計１５アドレスが設定可能になります。 無料プラン（5GBストレージ）のiCloudサービスはiCloudのままなので注意してください。 iCloud側の設定 まずは、iCloudにログインして「アカウント設定　＞　カスタムメールドメイン　＞　管理」に遷移します。 ポップアップでカスタムメールドメイン画面が開くので、「カスタムメールドメインを追加　＞　所有ドメインを追加」を選択します。 次に、追加するドメインの使用者を選択します。（あなただけ　を選択） 追加するドメインを入力し、「続ける」 入力したドメインの情報が表示されます。 手順２で既存のメールアドレスを追加しますが、（私の場合）追加はありませんでしたので「スキップ」を選択しました。 手順３のドメインレジストラの設定を更新するで「表示」を選択します。 表示された内容でドメインのレコードを修正します。 詳細(iCloudのヘルプの内容) MX： ホスト：[example.com]. 参照先：mx01.mail.icloud.com. 優先度：10 TTL：3600 ホスト：[example.com]. 参照先：mx02.mail.icloud.com. 優先度：10 TTL：3600 TXT： ホスト：[example.com]. 参照先：”v=spf1 redirect=icloud.com” TTL：3600 ホスト：[example.com]. 参照先：[設定中に提示されたパーソナル TXT レコード] TTL：3600 CNAME： ホスト：sig1._domainkey 参照先：sig1.dkim.[example.com].at.icloudmailadmin.com. TTL：3600 ドメインレジストラ（Route53）側の設定 AWSにログインし、「Route 53　＞　ホストゾーン　＞　ドメイン名」に遷移します。 以下のように入力し、レコードを作成します。 Lightsailにドメインを移管して使用している場合は、「Amazon Lightsail　＞　ネットワーキング　＞　DNSゾーン」で設定が必要です。 MXレコード 値にmx01とmx02を入れてください。 TXTレコード 画面上では”v=spf1 redirect=icloud.com”はTXTレコードとありますが、SPFレコードに設定する必要があります。 SPFレコード ”v=spf1 redirect=icloud.com”を設定します。 CNAMEレコード レコード名は”sig1._domainkey”を設定してください。 設定の確認 iCloud側に戻り、手順４の「セットアップを完了」から確認を実施します。 以下の表示が出れば完了です。 失敗の場合 失敗の場合は以下の表示が出ますので、設定を見直してください。 メールアドレスの追加 完了後の遷移画面の「メールアドレス追加」から追加する事ができます。 追加後すると、自動でFaceTime、iMessage、メールに紐づけられます。 最後に 今回のiCloud+のアップグレードで独自ドメインのメール運用が比較的安価（１３０円～）で行えるようになります。 iCloud+を使ってるよって方は是非、試してみてください。