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

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

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

LIST OF ARTICLES

記事一覧

  • テクログ

    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ありがとうございます。
  • テクログ

    gitの仕組みとかよくわからないけど、とりあえず使ってみる人用

    はじめにこれまで、gitってあまり触れてこなかったんですが、codecommitにlambdaコードを管理してるので、デプロイとかいろいろ便利なのでやってみました。gitってしっかり使いこなそうと思うと結構複雑なんだなとー理解はあとでいいから、とにかく使う!というところを書いて行きます。登場人物codecommitjenkins(デプロイでつかう。今回はほとんど登場しないです)sourcetree使った流れcodecommit(AWS)に、リポジトリを作って、ブランチを切ります。↓sourcetreeというgitを使うためのツールを使って、そのブランチにコードを置きます。↓jenkinsに作ったジョブでデプロイをします。という流れでつかいました。今回は、gitコマンドを中心にしていきます。他のツールは説明に必要な部分だけ使いかたとか書きます。細かく知りたい方は他のページをご参考に実際にやったことcodecommitでリポジトリを作る(これは、ブランチを入れるための箱のようなものです。)その中で、ブランチを作成。(これは、コードの置き場と作業場所のようなものです。と今は思っていただければいいかと思います。)sourcetreeを使って、リポジトリを自分のローカルに持ってきます。(ツールはgitが使えて、codecommitに繋げればなんでもいいかと)で、sourcetreeのホーム画面の右上にある、端末を使います。すると、黒い画面(CUI)が出ます。GUIよりも実はとっつきやすかったりしますよ。こういうやつここで、git checkout -b 新しいブランチ名 :新しいブランチを作成して、そのブランチに移動します。 masterという名前のブランチがあると思いますが、基本そこには何も置かないし作業もしないと思ってもらえればいいと思います。(運用の仕方にもよるので一概には言えないですが、基本的にはということで)git branch -a : リモートとローカルブランチの両方のあるなしが確認できます。あと、自分が今いるブランチの場所を*で教えてくれます。 ざっくり、リモートブランチは、codecommitにあるブランチローカルブランチは自分のPCにあるという感じのイメージです。ローカルブランチにcodecommitに置きたいファイルなどを持ってきます。たとえば、ファイルダウンロードして、そのディレクトリから、ローカルブランチにコピーとかで持ってきます。そしたら、git add . します。これは、今自分がいる階層にあるファイルをaddするよって意味です。git commit -m "最初のコミット" これで、コミット(確定させるみたい感じの意味です)して、これはなにをしたのかを -mオプションをつけて書いておきます。他の人が見た時に概要が掴めるようにです。git push -n :実際にpushするときは -nを取って実行する。 最後にpushします。-nはdry-run(実際にはpushしないで、もししたらどうなるかの結果を表示してくれます)これで、codecommit上に、自分が更新、作成をしたファイルを置くことができます。そしたら、デプロイしましょう。まとめリポジトリ作成↓リポジトリクローン↓ブランチ作成↓git add↓git commit↓git push↓デプロイ現場からは以上です。
  • テクログ

    PC画面を見すぎて疲れたのでディスプレイをグレイスケールに設定してみる

    どーも、ひなっちです。最近本で読んで、比較的手軽に目の疲れとか、集中できなくなってきたから、気分転換したいなーと思ったときにできるので良いなーと思ったのでシェアします!#はじめに長時間、ディスプレイを見続けていると、集中力が切れるし、目が痛くなってくることがあったのでグレイスケールを使ってみると目の負担が軽くなって、集中もしやすくなってよかったのでシェアします!#Maccommand + space-key > アクセシビリティ > ディスプレイ > グレイスケールを使用にチェックをいれればOKです。#Win10設定 > かんたん操作 > カラーフィルター > カラーフィルターオンwindowsキー + Ctrl + Cでもできます!*自分は普段Macユーザなので、win用のスクショはないんです。。#iPhone一般 > アクセシビリティ > ディスプレイ調整 > カラーフィルタ > グレイスケール#Android機種によって設定方法が異なります。僕が普段使っている、Fujitsuさんのarrows-M04-premiumを例にして設定を書きます。(他機種の方は調べて!)設定 > ユーザ > ユーザ補助 > 色反転やってみましたが、グレースケールというよりは、普段の眩しい、白い画面から、黒い画面に変更ができるという感じみたいです。。。#さいごに人間はいろいろな色が複数ある画面を長時間見てると疲れてくるし、集中力が散漫になるようなので、グレイスケールにして1色画面にすると気分の切り替えにもなるようです。目が疲れたな〜ってときの切り替え方法の1つとして、よければお試しください!