信頼はずっと、挑戦はもっと。

お問い合わせ
TEL:03-3496-3888

BLOG コアテックの社員ブログ (毎週月曜~金曜更新中)

LIST OF ARTICLES

記事一覧

  • テクログ

    Cloudwatch eventsでcronを使って 日か、曜日を指定するとき

    ひなっちです。Cloudwatch eventsでcronなんですが、地味に忘れて、ハマるんです。なぜか?普段、Linuxのcronタブに書いてる書き方とすこしちがうからです。Parameter ScheduleExpression is not valid. ↑これcron的には書き方正しいはずなのになーと今回、自分が少しはまったのが毎週金曜日、10時(JST)で処理を動かす場合でした。これを、そのまま素直にcronで書くと0 1 * * FRI * こうです。が、正解は0 1 ? * FRI * こうです。これ、ちゃんとマニュアルにも書いてあるんです。cron 式の日フィールドと曜日フィールドを同時に指定することはできません。一方のフィールドに値 (または *) を指定する場合、もう一方のフィールドで ? (疑問符) を使用する必要があります。https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/events/ScheduledEvents.html#CronExpressionsほんと地味ーーーにはまるし、普段cronタブに慣れ親しんでいるとマニュアル読むほどのものじゃない気もして、辿りつくまでに時間がかかりました。。。。では!
  • テクログ

    EC2の自動リカバリを設定できない。。だと?

    # どんな状況で起こったかアカウント間を移行して、移行先でAMIからEC2を起動させようとしたら、自動リカバリー(CloudWatchでステータスチェックアラートをトリガーにして、インスタンスを自動復旧させる機能のこと)がグレーアウトして、選択すらできない。。。# 自動リカバリ機能の条件ってなんだっけ?https://dev.classmethod.jp/cloud/aws/ec2-autorecovery-by-cloudwatch-alarm/#toc-ec2自動リカバリの条件こちらのページを参考にさせていただきました。# 原因インスタンスストアボリュームが付いていたからでした。#まとめ原因書いてしまうとなんだ、そんなことか。とは思ったのですが、移行元のEC2インスタンスには、インスタンスストアボリューム(Ephemeral Disk)は付いてなかったんです。だから、AMIを取得して、移行したらそのまま、付かないまま移行できると思ったら、、、、自動で付けてくれるんです。しかも、一旦作成したら、後から外せません、、、本番環境を他のアカウントに移行して、運用するときはメンテナンス時間を確保したりと、作業の手間の割には調整に時間が取られるので、自動リカバリ付けたい方は、ディスク設定でインスタンスストアボリュームにはご注意を。(ただ、本番システムの移行作業って神経使うし、移行テストのときも画面とか、ログとか見て異常ないよねっていう確認なので、気づきづらい部分ではあります)qiitaでも投稿してるよ!https://qiita.com/s-yana/items/947f53f0fdaef4833b1d
  • テクログ

    S3の同じリージョン間でサクッとレプリケーションしたいときのポリシーテンプレ

    同一リージョンでレプリケーションできるようになったんです。今までできなかったの?って感じはします。クロスリージョンで同じことはずっと前から使えましたからね。で、今日はポリシーのテンプレ貼ります。バケット名とアカウントIDを差し替えれば使える感じです。とりあえず、クロスアカウントと同一アカウントでレプリケーションするための方法なので、それ以外のことやりたいときは改変して、使ってみてくださいーS3に大して何かやりたいときって、そのS3バケットの所有者がどのアカウントかが重要です。つまり、同一アカウント内だったら、みんなAアカウントが持ってるのでIAMロールでS3リソースに何ができるかを設定したらOK。BアカウントにあるS3バケットに大して、Aアカウントから何かをしたいとき。これは、AアカウントでIAMロール設定とBアカウント側でバケットポリシーの設定が必要になります。同一アカウントでレプリケーションするときのIAMロールにつけるポリシー {     "Version": "2012-10-17",     "Statement": [         {             "Effect": "Allow",             "Action": [                 "s3:GetReplicationConfiguration",                 "s3:GetObjectVersion",                 "s3:GetObjectVersionAcl",                 "s3:GetObjectVersionTagging",                 "s3:ListBucket"             ],             "Resource": [                 "arn:aws:s3:::source-bucket",                 "arn:aws:s3:::source-bucket/*"  <転送元バケット             ]         },         {             "Effect": "Allow",             "Action": [                 "s3:ReplicateObject",                 "s3:ReplicateDelete",                 "s3:ReplicateTags"             ],             "Resource": "arn:aws:s3:::dist-bucket/*" <転送先バケット         }     ] } Getの部分を省略して書くこともできます。たぶん、S3://Replicateも短縮できるかもですが、実際試してないのでたぶんです。{     "Version": "2012-10-17",     "Statement": [         {             "Effect": "Allow",             "Action": [                 "s3:Get*",                 "s3:ListBucket"             ],             "Resource": [                 "arn:aws:s3:::source-bucket",                 "arn:aws:s3:::source-bucket/*"  <転送元バケット             ]         },         {             "Effect": "Allow",             "Action": [                 "s3:ReplicateObject",                 "s3:ReplicateDelete",                 "s3:ReplicateTags"             ],             "Resource": "arn:aws:s3:::dist-bucket/*" <転送先バケット         }     ] } S3の認証周りでポリシーを設定するときって、単純にレプリケーションしたいだけでもいろいろActionに書かなきゃいけないのでとりあえず、なにも考えずにアスタリスク!でいいとおもいます。クロスアカウントでレプリケーションするときにつけるバケットポリシー {     "Version": "2008-10-17",     "Id": "S3-Console-Replication-Policy",     "Statement": [         {             "Sid": "S3ReplicationPolicyStmt1",             "Effect": "Allow",             "Principal": {                 "AWS": "arn:aws:iam::アカウントID番号:root"             },             "Action": [                 "s3:GetBucketVersioning",                 "s3:PutBucketVersioning",                 "s3:ReplicateObject",                 "s3:ReplicateDelete"             ],             "Resource": [                 "arn:aws:s3:::dist-bucket",                 "arn:aws:s3:::dist-bucket/*" <転送先バケット             ]         }     ] } 転送先のバケットがあるアカウント側のバケットポリシーにいれましょう。クロスアカウントのIAMロールを作るこれ地味に忘れてて、すこしはまったんですが、このロールは、転送先のアカウントで作成します。転送元のアカウントからのリソース操作を許可するので。これでとりあえず、レプリケーションとかaws-cliで同期をしたいとかはできます。案外これ使うんで、お役に立てばうれしいです。「とりあえず、S3の中身同期しといて、レプリケートかけるようにする」がやれます。現場からは以上です。
  • テクログ

    AWS-CLIコマンドでEC2のメトリクスをいろいろ取りたい

    # aws-cliコマンドさくっと、EC2のインスタンスの情報をcliで取りたいときのコマンドです。##EC2のタグについてるサーバの名前を知りたい時aws ec2 describe-instances | jq -r '.Reservations[] .Instances[] .Tags[]|select(.Key=="Name")|.Value' #ステータスがrunning状態のTagsがKey=Nameのをインスタンスを取得aws ec2 describe-instances --filter "Name=instance-state-name,Values=running" | jq -r '.Reservations[] .Instances[] .Tags[]|select(.Key=="Name")|.Value' #running状態かつ、 TagsがKey=NameのインスタンスIDとインスタンス名を取得aws ec2 describe-instances --filter "Name=instance-state-name,Values=running" | jq -r '.Reservations[].Instances[] | {InstanceId, InstanceName: (.Tags[] | select(.Key=="Name").Value)}' #インスタンス名だけを抽出して、整形して出力aws ec2 describe-instances --filter "Name=instance-state-name,Values=running" | jq -r '.Reservations[].Instances[] | {InstanceId, InstanceName: (.Tags[] | select(.Key=="Name").Value)}' | grep "InstanceName" | awk '{print $2}' | sed -e 's/"//g' -e 's/,//g' > hogeファイル #インスタンスIDだけを抽出して、整形して出力aws ec2 describe-instances --filter "Name=instance-state-name,Values=running" | jq -r '.Reservations[].Instances[] | {InstanceId, InstanceName: (.Tags[] | select(.Key=="Name").Value)}' | grep "InstanceId" | awk '{print $2}' | sed -e 's/"//g' -e 's/,//g' #EC2についてるEIPを取得aws ec2 describe-addresses --query '*[].PublicIp' --output text | tr '\t' '\n' #ローカルPCからAWSへ取得したEIPリストを使ってSSHして、コマンド叩く用のシェル#!/bin/bash aws ec2 describe-addresses --query '*[].PublicIp' --output text | tr '\t' '\n' > elastic_ip.lst export AWS_HOME=${HOME}/.aws export AWS_CONFIG_FILE=${AWS_HOME}/config export ELASTIC_IP=${HOME}/elastic_ip.lst cat ${ELASTIC_IP} | while read line do ssh -n user@$line -p 22 -i /xxxxxx/xxxxxx 'example-command' > result.txt done
  • テクログ

    AWSのS3のクロスアカウントでとりあえず転送するときのポリシー

    はじめにここ最近、クロスアカウントでデータの転送をしたりと、アカウントまたぎで作業する機会が多くなってるので、ロールとかポリシーとかを作成したんですが、なんとなく理解はしているけど、よく使う部分かつ、セキュリティーにも関わる部分なので理解するために記事にしようと思います。ロールとかポリシーってなんすか?ロールは日本語でいうと、役割。ポリシーは方針のことです。AWSでの設定例でいうと、たとえば、EC2からS3にあるデータに何かさせたい場合。EC2から、S3にあるAバケットにアクセスして、そこにあるデータを上書きする役割を付けたとします。その役割を果たすためにの方針を作成して、それをロールにくっつけてあげます。つまり、ロール+ポリシー=【誰がどのリソースに、何ができるのか】を決めて、それをセットにして、リソースに設定をくっつけてあげることでAWSのリソースを操作していくってことなんです。S3の認証ロール、ポリシーの作成って、やりたいことによっていろいろ設定する方法があるので、ここでは自分がはまったS3の認証周りを例にしてみたいと思います。クロスアカウントでとにかく転送したい場合Aアカウントの転送元バケットからBアカウントの転送先バケットにとりあえず、転送したい場合。これは、単純に、Bアカウント側のバケットポリシーでAアカウントからの操作するためのアクセスを許可してあげればOKです。バケットポリシーの例{   "Version": "2012-10-17",   "Id": "Policyxxxxxxxxxxxx",   "Statement": [     {       "Sid": "Stmtxxxxxxxxxxxxx",       "Effect": "Allow",       "Principal": {         "AWS": "arn:aws:iam::AアカウントID:root"       },       "Action": "s3:*",       "Resource": [         "arn:aws:s3:::xxxxxx-test-backet",         "arn:aws:s3:::xxxxxx-test-backet/*"       ]     }   ] } Aアカウントから、BアカウントのS3バケットに対して、なんでもできるよというバケットポリシーになります。やりたいことに合わせて、できることを絞っていくとよりセキュアに使うことができますが、とりあえず転送するために穴開けたい、あとで閉じるよ〜くらいの使い方をしたいときにこういう書き方をするとOKです。さいごにS3の認証って他にもいろいろあって掘っていくともっといろんな使い方できるんすけど、今回はこんな感じで。
  • テクログ

    AWSのssmってコスパがいいと思う

    #はじめにAWSって簡単にサーバ建てたり、いろいろなことをポチッとするとすぐ動かせていいですよね。ただ、簡単に建てられるので、管理するのが大変だったりしません?ssm入れるといろいろさくっと行けそうな感じなので、そこらへんを書こうと思います。#EC2にssm入れようと思った経緯たくさんのEC2の管理がめんどくさいなと思ったので、Run_commandとか使ってまとめて管理をしたいと思ったため。#ssmって何ができるんすか?ssmの正式名称は、AWS system managerです。機能としては、awsリソースのマネージメントをするってこと、つまり管理ができるんです。リソース管理って全部?一部どこまでなんでしょうか、あと他にはどんな機能があるんでしょうか。#SSMの項目一覧何ができるか、運用管理で使われやすそうなところをざっくりと調べてみました。細かい部分は今回は割愛してます。ここは、OpsCenterです。ここの項目って、OpsItemという単位で、運用上の問題を管理するってことなんです。たとえば、CloudWatchが検知した、あるイベントが起こったら、EC2を停止してしまうとか、cloudwatchで設定できるものとは違ったすこしカスタマイズしたトリガーを作れたりします。アクションと変更ここは、オートメーションですね。管理の自動化の部分なんですが、たとえば、Linuxのパッチ適用をされた状態の最新AMIを取っておけるので、オートスケーリンググループを更新できたりします。インスタンスとノードここは、セッションマネージャーとコマンド実行です。セッションマネージャーは、AWSコンソールからsshをできる機能なんすが、料金無料で、sshキーの管理不要になります。まあ、クラウドなんで、本来はこういう使い方をするのが良いはずです。サーバに直接ログインも基本的には不要になるんで、運用も手間が減りますね。コマンド実行です。これは、Run_commandという機能を使って、ssmのエージェントを入れて、管理しているインスタンスに対して、コマンド実行できるものです。例えば、全インスタンスのカーネル情報が見たいとか。一回叩けば、情報をまとめて取得可能です。これも無料です。共有リソースパラメータストアは、秘密データと設定データをまとめて管理することができます。たとえば、DBの平文データとか、パスワードとか、設定データとか外にバレて、悪用されると、とてもまずいものをまとめて管理OKですってかんじですね。しかも、管理すると、コードから上記の大事なデータは分離できるというメリットつきです。料金は、スタンダードタイプなら基本無料ですが、APIの叩く回数が上限を超えると追加課金をされるというイメージですね。#さいごにざっと書いてみましたが、ssmの印象はコスパ良しってところです。基本的な使い方なら、それほど追加料金が発生せずに、やりたいことができるっていう印象でした。目標は、サーバに入る必要ありませんってところまでやりたいなと思います。参考記事:https://qiita.com/numasawa/items/ed1f1ef6c7c3c6b4c56b#%E8%BF%BD%E8%A8%98-2018%E5%B9%B410%E6%9C%88ありがとうございます。