Vain Effort

まえおき 　CloudFormationを使っているとスタック(Stack)の更新をすることがある。今までCloudFormation内をリソースを更新したときに、更新されなくて戸惑った3つの場合について書いてみる。   1. LambdaのコードをS3に保存した場合 　当たり前かもしれないけど、その更新は最新のCloudFormationのテンプレートと旧テンプレートの差分より更新される。つまり、「 テンプレートに変更がないとスタック内のリソースに更新は発生しない 」ということだ。 AWS::Lambda::Function の Code 属性の記載方法には２つがある。テンプレート内に直接記載する方法とS3にファイルをアップロードし、そのバケット名とパスを記載する方法だ( 関連ドキュメント )。ここで更新時に問題になるのはS3にLambdaファイルを更新する場合だ。S3のファイルを更新しても、CloudFormationテンプレート内のコードは変わることなく、S３ファイルの変化の検知もしないので、Lambdaが更新されない。私は以下の2つの方法で更新した。   方法１ S3パスを更新する 　シンプルな方法である。 AWS::Lambda::Function の Code 属性を変更すれば、テンプレートに変更点が発生するのでLambdaを更新するｋとおができる。私は日付ごとにフォルダを作成、更新するLambdaをおきテンプレートを修正するようにしていた。しかし、当時はCI/CD環境ではなかったので、テストでLambdaに修正点があれば、都度S3にファイルをアップロードして日付を修正＆デプロイまたはテンプレートをロールバック＆デプロイする必要があった。ミスも多く発生していた。そこで、CI/CD環境を整えることと同時に方法2の方法を利用することにした。   方法2 SAMを利用する(おすすめ) 　SAM(Serverless Application Package)　を利用する方法だ。SAMテンプレートを書いて、コマンドを実行すると以下が実行される。 Lambdaファイルはランダム文字列のファイル名でS3にアップロードされる テンプレートをCloudFormationテンプレートに変換して、S3にアップロードし...

まえおき 　最近、AWS DevOps Engineer - Professionalを取った。今年の面談でDevOps Engineer資格自体は今年取ります＆なので研修行きたいですと話したので、2つの研修(DevOps Engineering on AWS、Advanced Developing on AWS)を受けて、受験する予定ではあった。いつ受けるか考えていた中、たまたまサンプル問題を解いてみたら「割といけるんじゃない？」と根拠なき自信にあふれて2週間後のテストセンターを予約。そして、運よく合格したので、3年後の更新に備えてメモ。(最近投稿が少なかったのもあるし)   筆者のスペック 入社4年目、AWS経歴は2年くらい 業務でAWSを使っている AWS関連作業の自動化業務をやっており、最近はStepFuncions、Cloudformation、Codepipelineを浅く触っている Solution ArchitectのProfessionalを持っている Advanced Developing on AWS を受講済   「AWS DevOps Engineer - Professional」について 試験ガイド を参考にすると、6つの分野から出題されるらしい。 分野 1: SDLC(Software Development Life Cycle)の自動化 22% 分野 2: 構成管理およびInfrastructure as Code 19% 分野 3: 監視およびロギング 15% 分野 4: ポリシーと標準の自動化 10% 分野 5: インシデントおよびイベントへの対応 18% 分野 6: 高可用性、フォールトトレランス、およびディザスタリカバリ 16% 　もう受験して2か月くらい経つので内容はほぼ覚えてない(...)。 　覚えている範囲で書くと、まずはCI/CD系の内容。CodeシリーズとElastic Beanstalkのサービスと絡めて,上記の内容を聞く問題が出るような感じ。例えば、「ブルー/グリーン構成をElastic Beanstalkで構成したけど、問題が発生。どう直せばいいか」や「こういう構成で開発からデプロイまで自動化したい。どうすればよいか(選択肢にはCodeシリー...

まえおき 今週あったチーム先輩(Aさん)との会話 私　：CloudFormationテンプレートにStepfunctionsを書こうとするとyamlにベタ書きしかできないんですよ。 　　　これが私がCDKを押す理由の一つなんですよ。 Aさん：LambdaみたいにS３バケットに定義ファイルを置いてそのパスをyamlに書けばいいじゃん。 私　：あれ?私が調べたときはそれができなかったので、今あるテンプレートはすべてベタ書きにしているんですが…。 Aさん：うん?これでできないんだけ？(CloudFormationのドキュメントURLを共有) 私　：できるじゃん!? 　送られてきた CloudFormationドキュメント を見ると、 DefinitionS3Location というプロパティがあった。おかしいな…調べたときは本当になかったんだようなーと思いずつ更新履歴を見ると、2020年5月20日更新。私が調べたのは1月ごろだったから、その時はなかったということだ。うーん、What's Newはほぼ毎日見るけど、使っているサービスのドキュメント更新履歴も頻繁にチェックしないといけないのかな…。とりあえず、試してみることにした。   DefinitionS3Locationを試してみる Step Functionsのテンプレートを準備 　State Machineの定義はAWSドキュメントの Getting Started with Step Functions にあるコードから最後のstateを少し変えた簡単な以下のコードを利用する。 DefinitionSubstitutions も使ってみたかったので。 DefinitionSubstitutions はテンプレート内で同時に作成されるリソースをState Machine内で利用する場合に使う。例えば、Lambdaを作成して、それをState machineに入れるとか。(LambdaのARNが必要になる)   　jsonファイルで保存し、S3のバケットに保存する。 　これでStep Functions側の準備は終わり。   CloudFormationテンプレートを準備 　 CloudFormationの StepFunctions::StateMachi...

まえおき AWS CDKが使いたいです…。 私は今までCLI＆手作業でやってきたAWS関連業務をWebページのボタン1つでできるように簡略する業務を担当しています。何もないアカウントに環境を構築する業務が多いため、必然的にCloudFormationを多く使うようになります。CLIやGUI手作業で作成するよりは便利ですが、テンプレートを書いてると、「もうちょっといい方法ないかな…」と思う時がありました。例えば… yamlの書き方があまり慣れない 配列や連想配列などなど サービスによって(例えば、API Gateway)書かないといけないものが多い SAMを使えば一部解決はできますが…。 使いまわしができない(For文など) 例えば、名前は違うが設定が同じリソースを全部テンプレート書かないといけない ミスの確認が難しい vscodeやpycharmでcfn-lintを利用すればいいものですが、チームのデフォルトエディタはcloud9なんですよね… Lambdaの場合は、事前にS3にアップロードするか、テンプレート内に記載しないといけない S3の場合はzipしてS3にアップロードするPipelineを作ればできそうではありますが、テンプレート記載はメンテ辛いですよね…。 StepFunctionの場合は、コード(Amazon State Language)テンプレート内に記載しないといけない これはS3にアップロードもできなく困ってました。あと、書き方にもちょっと苦労してましたね。 DefinitionS3Locationという属性がアップデートされてS3から定義ファイルを読んでくることが可能になりました。 といったことですね。 そう思っている...

まえおき 　最近久々にCloudWatch Events(以下、Events)の画面を開いたら、以下のようなメッセージが出ていた。 グーグル翻訳先生に翻訳をお願いすると CloudWatch Events is now Amazon EventBridge Amazon EventBridge (formerly CloudWatch Events) provides all functionality from CloudWatch Events and also launched new features such as Custom event buses, 3rd party event sources and Schema registry to better support our customers in the space of event-driven architecture and applications. CloudWatch EventsがAmazon EventBridgeになりました Amazon EventBridge（以前のCloudWatch Events）は、CloudWatch Eventsのすべての機能を提供し、カスタムイベントバス、サードパーティイベントソース、スキーマレジストリなどの新機能も起動して、イベント駆動型のアーキテクチャとアプリケーションの領域でお客様をより適切にサポートします。 らしい。Amazon EventBridge(以下、EventBridge)がEventsの代わりになるということだった。いつから出たんだろう…。最近、画面のUIが変わりましたのメッセージが常にほぼどのサービスでも同じ感じで出ていたから全然気つかなかった…。今までは、EventBridgeというEventsと似ているサービスがあるということは知っていたけど、Eventsの機能で十分だったので特に気にしてなかった。調べてみると、ちょうど1年前に発表されたサービスだった。( Amazon EventBridge – SaaS アプリケーション用のイベント駆動型での AWS の統合 )   Cloudwatch EventsとAmazon EventBridgeの違い 　全く同じサービスであるというと若...

まえおき このポストはQiitaに書いた Raspberry piで apt upgradeがconnection time outになるとき を移したものです。   背景 また、新しくRaspberry piフォーマットし、インストールしたので、いつもの儀式で sudo apt update と sudo apt upgrade を行いましたが、うまくいきませんでした。 大体以下のようなエラーでした。 Err:319 http://ftp.tsukuba.wide.ad.jp/Linux/raspbian/raspbian buster/main armhf sc3-plugins-server armhf 3.9.1~repack-3 Unable to connect to ftp.tsukuba.wide.ad.jp:http: 39% [Working] Fetched 204 MB in 3min 9s (1,078 kB/s) E: Failed to fetch http://ftp.tsukuba.wide.ad.jp/Linux/raspbian/raspbian/pool/main/c/cron/cron_3.0pl1-134_armhf.deb Could not connect to ftp.tsukuba.wide.ad.jp:80 (203.178.132.80), connection timed out E: Failed to fetch http://ftp.tsukuba.wide.ad.jp/Linux/raspbian/raspbian/pool/main/e/expat/libexpat1-dev_2.2.6-2_armhf.deb Unable to connect to ftp.tsukuba.wide.ad.jp:http:   解決 以下のファイルを開き、mirrorサイトを変更して解決しました sudo nano /etc/apt/sources.list 書いてあるURLをコメント処理して、新しいミラーサイトを入力します https://www.raspbian.org/RaspbianMirrors/ にミラーサ...

まえおき 　日本に住んで1n年ほど過ぎているが、日本語で技術書を読むとあまり集中力が持たず(小説は問題ないので、技術書を日本語で読む習慣ができてないだけだとは思うけど)、母国語で読みたいと思っていた。最初は電子ブックリーダーを買おうかと思ったが、多用途で使えそうなタブレットを買うことを決め、どのモデルを買うか2か月ほど悩んだ。そして、ストレスフルだったある日、AmazonのFire10を衝動買いした。そして、狙ったかのように購入2日後にタイムセールで5000円割イベントが開始された…。 　届いたタブレットで初めて読んだ本が「The Software Craftsman: Professionalism, Pragmatism, Pride」だ。訳すれば、「ソフトウェア職人精神：プロ意識、実用主義、プライド(誇り)」といったものか。Craftsmanshipは辞書では職人技と出てくるが、本の内容を読むと職人精神のほうがよりベターな気がする。(日本にはまだ翻訳本が発売されてなさそうだ) 　本の内容とは若干外れるかも知れないが、SIerの会社に入って、今は幸い自分をエンジニアと言えるような手を直接動かせるやりたいと思っている業務にかかわっている(もちろん全部ではないが）。しかし、年次が上がるとマネジメント業務をいやでもやらないといけなくなり、先輩たちを見ていると開発ツールよりエクセルやパワーポイントを触っている時間が多いように見える。このままだと、自分では手を動かす時間がどんどん少くなり、開発に関してはメンバーにタスクを渡し、進捗管理するだけになりそう。もちろん、プロジェクトにはマネジメントも大事とは思う。しかし、マネジメントの業務が主になった自分を私はエンジニアと呼べなくなりそうだった。 　一方、今担当している業務は小さい規模ということもあり、バックエンドからフロントエンドまで一人で構築している。自分なりには頑張って構築または開発しているわけだが、後から見ると、「こうしたほうがよかった」と後悔するところが出てきてしまう。また、今後新しいメンバーが複数人入ることになり、リーダ(一応)として、開発を進めていけばいいかという悩みもある。(マネジメントの話と合わせて、こうして自分の開発時間が減るのは悲しいと思いずつ…)　 　こうして頭が想いいっぱいになっていて、今の...