AWS SAM テンプレートへのリソースインポートは意外と大変？ 転ばぬ先の杖として事前に確認してみました。 ちょっとしたサーバレスアプリケーションを作るとき、AWS SAM は便利です。 AWS SAM のテンプレートは AWS CloudFormation テンプレートの拡張機能なので、リソースのインポートも簡単にできると思ったのですが、ひと手間必要だったのでその手順を紹介したいと思います。 背景 AWS SAM で Lambda 関数を作成する際、テンプレートに記載しなくても CloudWatch Logs のロググループが作成されます。 テンプレートに記載しない場合、このロググループは AWS SAM のリソースとして管理されないので、スタックを削除してもロググループが残り続けます。 AWS SAM の管理対象ではないリソースに対して、変更を加えたい場合は別の手段で行う必要があり、
概要 ESLintのプラグインとVS Codeの設定でimportの追加・削除・整列を自動化して幸せになれる記事です。 こんな人におすすめ チーム間でimportの順番などのルールが決まっておらず。人によってフォーマットがバラバラなのが実は気になっている。 未使用のimportを消すのを忘れがち。 コンポーネントやライブラリの関数を書いたら勝手にimportしてくれたら嬉しい。 import周りを触るのがシンプルにめんどい。 使用するプラグインと設定 VS Codeの設定 source.addMissingImports importの自動追加に使用する VS Codeで設定する ESLintのプラグイン eslint-plugin-import importの整列に使用するプラグイン eslint-plugin-unused-imports 未使用のimportを削除に使用するプラグイン
SREチームの今です。 カヤックでは、クラウドリソースの管理にはTerraformを利用することが多いです。 クラウドリソースの構成や設定をコードで管理することで、リソースの変更内容の差分をレビューできる、意図しない設定変更を発見できるなどの利点があり、SREの目的であるサービスを安定して提供する上で重要な要素の一つです。 実際の作業として、既に運用中のサービスを新たにTerraform管理下に置く場合や、多くのリソースが既にweb consoleから作成されているものをTerraform管理下に追加する場合も多いと思います。 その際にはTerraform importをする必要があります。しかし、Terraform importは単純作業とはいえ時間と手間がかかり、優先順位を下げてついつい後回しにしてしまうことも多いのではないでしょうか。 今回は、手作業でTerraform import
AWS Cloud Development Kit(AWS CDK)の利用ノウハウを増やすべく、EC2インスタンスを立ち上げてみました。 公式ドキュメントやGitHubのソースを眺めたらだいたいは実装できるのですが、ハマりポイントがちらほらとありました。 AWS Cloud Development Kit(AWS CDK)ってなんぞ？という方は下記をご参考ください。 AWS クラウド開発キット (CDK) – TypeScript と Python 用がご利用可能に | Amazon Web Services ブログ https://aws.amazon.com/jp/blogs/news/aws-cloud-development-kit-cdk-typescript-and-python-are-now-generally-available/ 前提 AWSアカウントがある AWS C
aws configure でアクセスキーを手打ちせず aws configure import で CSV ファイルからインポートしてみた コンバンハ、千葉（幸）です。 AWS CLI （など）を使用するためにアクセスキーを設定する際、皆さんは以下のような手順をとるのではないでしょうか。 「ひとまずaws configureを叩く。」 $ aws configure ↑（--profileオプションを付与すれば名前付きプロファイルへの設定となりますが、デフォルトではdefaultというプロファイルに対する設定となります。） 「各項目の入力が促されるため、必要な項目を入力していく。」 $ aws configure AWS Access Key ID [None]: #アクセスキーを入力 AWS Secret Access Key [None]: #シークレットキーを入力 Default
はじめに いつもはes6のモジュール管理方式であるimport/export(ES modules)を使って、npmで手に入れたライブラリや自分で作成したモジュールをロードしているが、たまに思った挙動にならないことがある。また、export defaultしたモジュールをテストしようとしてkarmaでrequire()するとエラーになったりした。そういう場合は、とりあえずmodule.exportsを使ってみるとうまくいったりすることが多いのだが、なぜなのかはあまり考えていなかった。 ということで、実際にはどうなっているのか、またモジュールシステムとは何なのかという点で基本的なことから理解を深めて、es6のimport/exportとの違いを知り、より正しく実装できるようになれば良いと思っている。 結論としては 方針としては基本的にはES6形式で記述するが、CommonJS形式の読み書きが
Amazon Web Services ブログ 新機能 – CloudFormation スタックへの既存リソースのインポート AWS CloudFormation を使うと、インフラストラクチャ全体を、テキストによりモデリングできます。この方法により、インフラストラクチャをコードのように扱うことが可能になり、ソフトウェアのバージョン管理やアーキテクチャ上の変更をデプロイ前にチームでレビューするなど、ソフトウェア開発のベストプラクティスを適用できるようになります。 初期段階でコンソールや AWS Command Line Interface (CLI) から作成された AWS リソースは、CloudFormation での管理が必要となる場合があります。たとえば、お客様 (あるいは他のチーム) で、 IAM ロール、仮想プライベートクラウド、または RDS データベースなどを移行の初期段階
実は以前に別の場所でも書いたのですが、今回Google Page Speedの方でも少しだけ触れられていたので、改めてまとめ。 自分でも経験があることなのですが、開発をやっているとどうしても、構造をモジュール化して複数のファイルに分割して管理したくなります。 StyleSheetにおいても同様で、プレゼンテーション層のコンポーネントにあわせてCSSを用意し、ページ構成にあわせて取り込むようなことをやりたくなるでしょう。 しかしその際、@import構文を使うのはパフォーマンスと挙動の両方に有害である可能性が高いと、「」の著者としても知られるSteve Souders氏が警鐘を鳴らしています。 使うべきでないポイント @importは、大きく分けて2つの観点で「使うべきでない」とされています。 ひとつは、パフォーマンスの問題。StyleSheetはほぼ全ての主要ブラウザでパラレルロードがサポ
CakePHP Advent Calendar2010、残りちょうど10日となりました。 15日目担当のひろみです。よろしくお願いします。 いんとろだくしょん どんなCakeアプリケーションでも使うといっても過言では無いのがApp::import()です。 直接使うことはなくても、ヘルパーやコンポーネントをコントローラで指定すると、間接的にApp::import()を使っていることになります。（もっと言えば、dispatcherを呼ぶだけでApp::import()は呼ばれますが・・・） そんな名脇役、App::import()について、既知の事実も含めて、詳しい挙動を追いかけてみましょう。 App::import()の歴史 CakePHP1.1までは今となっては懐かしい、uses()やvendor()を使っていました。 ヘルパやコンポーネント、モデルの読み込みすらも、グローバル関数を使っ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
