開発者体験を変えるInfrastructure as Codeの新機能6選！AWSにおける最近のInfrastructure as Code (IaC) のアップデートからピックアップしてご紹介します。 JAWS Days 2024 のLT資料 (4分枠) です。
Testing HashiCorp Terraform
Sign up for freeGet started in minutes with our cloud products TerraformInfrastructure as code provisioning
Infrastructure from Code (IfC) ツールまとめ - maybe daily dev notes
昨今Infrastructure from Code (IfC)という概念をよく耳にします。先日もAWSのGregor Hohpeが関連する記事を書いていました。 architectelevator.com この記事では、Infrastructure from Codeとはなにか簡単に紹介し、具体的にどのようなツールがあるか網羅的にまとめます。 Infrastructure from Codeとはなにか Infrastructure from Code (IfC) とは、その名の通り、Infrastructure as Code (IaC) に関連する概念です。IaCとの根本的な違いは、IaCは開発者がインフラを明示的に意識して構成を記述するのに対し、IfCでは開発者がインフラをできるだけ意識しないよう抽象化を試みていることです。これにより、差別化に繋がらない重労働ができる限り排除された高
未知のサービスに対するTerraform初心者アプローチ
私を含めた最初からTerraformを使おうとして挫折した方々，いかがお過ごしでしょうか この記事では，Terraformで未知のリソースを定義しようと思ったときに私がしていることを紹介しています．読者対象としては「Terraformを導入したはいいけれど，リソースの定義方法がわからないまま挫折して自然消滅させた方」を対象としています．まあ，Terraformの公式ドキュメントを読んでわかる人は直接の対象ではありませんが，「こういう人もいるんだな」くらいで見ていただければ幸いです． 口を大にして言いますが，この記事の合言葉は 「公式ドキュメントを読んでわかるならそれに越したことはない」 です．そのうえで，公式ドキュメントを読んでわからなかった人が，Terraformを利用するるための足がかりをこの記事ではECS on Fargateのサービス作成とS3バケットの作成を例に挙げながら提案して
DNSレコードをTerraformで管理してたけどやめた
DNSレコードをTerraformで管理していたドメインがありました。(Route53) IaC(Infrastructure as Code)は当然のようになっていてこのドメインもTerraformで管理していました。 しかし運用していくにつれ今の構成に不満点も出てきてて, なんかいい感じに出来ないかな~と思っていました。 Terraformで管理しているけど, 管理するレコード数が多くなるにつれ terraform plan や terraform apply の実行に時間がかかるようになってきた CircleCI使って自動化してるからデプロイ待たないで違うことしてればいいんだけど, そこまで何か違うことできるほど時間かかるわけじゃないから結局待っちゃってストレス そもそもコード化してるけど, このドメインに関していうとプルリク作ってレビューしてapply!みたいな慎重な手順は踏む必要
コードによる管理がどうだったら良さそうか - Qiita
これは CDK Advent Calendarの 6日目のエントリーです。 みなさんこんにちは。大村(@yktko) です。 ときどき Infrastructure as Code (IaC) を頑張った結果辛くなってしまったという話を聞いており、以前 JAWS DAYS でこんな LT をやらせていただいたことがあります。 AWS社員による怒涛のLTチャレンジ! Infrastructure as Codeに疲れたのでなんとかできないかCDKで色々やってみる このLTでは勢いで話してしまったのですが、このエントリーでコードによる管理がどうだったら良さそうなのか、自分の経験を元に整理してみます。文中に出てくるプレゼン資料はこのLTからとっています。 なお、システムの運用は状況によって適切なやり方が異なります。これが一般に通用する正しい方法だとは思っていませんが、一つの考え方だと思って読んで
Infrastructure as Codeに関する技術書籍を執筆しました - How elegant the tech world is...!
Overview タイトルの通りですが、技術書博5向けにInfrastructure as Code (IaC)に関する技術書を執筆しました。 gishohaku.dev 一応、僕がそれなりにAWS x IaCにどっぷり浸かっていることもあり、題材のクラウドはAWSを主軸にしています。 TerraformやPulumiに関しては、別にAWSに限らずAzureやGoogleCloud利用者の方々にも通ずる部分があると思います。 執筆に至ったモチベーション 僕自身、IaCサービスに関してはCloudFormation 数ヵ月、terraform 2年、Pulumi 8ヶ月ほど経験しており、 それぞれの特徴も知れてきたのでナレッジを形にしたいなと思い、同僚と執筆しました。 ※ちなみに、共著の同僚である@HorseVictoryはAWS Top Engineersの一人です。 クラウドネイティブな
Announcing HashiCorp Terraform 1.0 General Availability
Sign up for freeGet started in minutes with our cloud products TerraformInfrastructure as code provisioning
最近、Terraform のベストプラクティス迷子です - サーバーワークスエンジニアブログ
技術 1 課の水本です。 最近 Terraform のリファクタリングを行っているのですが、ベストプラクティス迷子になっています。 HashiCorp でも明確な方針は打ち出していない為、Terraform を利用する各プロジェクトで方針を決めているのが現実のようです。 今回は私が出会ってきた問題と、それについての対応、見解を書き連ねていきます。 あくまでも私が思ったことですので、「こうしたほうがいいよ！」というネタも募集しています。 workspace 使うのか使わないのか問題 結論として、私自身は workspace という機能を知ったものの、使うことは考えませんでした。 Terraform では workspace という個別のエリアを設けることが可能で、これを prod や staging と命名し作成しておくと、完全に環境を分離できるというメリットがあります。 ただしデメリットと
AWS クラウド開発キット (AWS CDK) v2 および Go CDK が開発者プレビュー用に利用可能になりました
AWS クラウド開発キット (AWS CDK) v2 が開発者プレビュー用に利用可能になり、CDK ユーザーは 2 点の新機能が使えます。1 点目は、すべの CDK バージョンが Go 言語をサポートし、コードとしてのインフラ (infrastructure-as-code) の定義およびAWS CloudFormationによるプロビジョニングに開発者が使えるプログラミング言語の数が増えます。2 点目は、AWS Construct ライブラリのすべての安定した構造体が単独の分離したパッケージで利用可能になり、CDK の利用およびそれをさらに進化させた新バージョンへの追随を容易にします。 AWS CDK v2 において AWS Construct ライブラリが aws-cdk-lib という名前で 1 つのパッケージに統合され、使用する各 AWS のサービスごとのパッケージをダウンロードす
インフラ構成ツールの「Pulumi 3.0」正式リリース。APIでPulumiを呼び出し可能、クラウドのアップデートに即時対応など
インフラ構成ツールの「Pulumi 3.0」正式リリース。APIでPulumiを呼び出し可能、クラウドのアップデートに即時対応など コードを用いてクラウドをはじめとするITインフラの構成を定義できる、いわゆるInfrastructure as Codeツールの「Pulumi」が、最新版となる「Pulumi 3.0」として正式リリースされました。 Announcing our new #CloudEngineering Platform (Pulumi 3.0)! Native providers with 100% API coverage Pulumi Packages to share #cloud components Automation API for programmatically deploying infrastructure from code Enterprise-g
Infrastructure as Code の静的テスト戦略 #DevOpsDaysTokyo / DevOpsDays Tokyo 2021
DevOpsDays Tokyo 2021 で使用したスライドです。 Infrastructure as Code を導入してみたはいいけれど、デプロイしてみたらなぜか上手く動かない。そんな経験はありませんか？ 本セッションでは、実際の環境を構築する「前」に、IaC のコード自体に対してテストを行う手法について解説します。 ご存知の通り Infrastructure as Code (IaC) は、インフラをコードで定義することを通し、アプリケーション開発のベストプラクティスをインフラ領域にも輸入しようとする方法論です。IaC の考え方は近年急速に普及し、開発フローの一部として種々の IaC ツールを利用することは半ば常識のような状態にあります。 しかし同時に、IaC は銀の弾丸ではありません。特に組織的な導入を考えようとすると、得てして「なぜか上手くいかない」「余計に運用が辛くなってしま
Announcing HashiCorp Terraform 0.15 General Availability
Sign up for freeGet started in minutes with our cloud products TerraformInfrastructure as code provisioning
AWS CDKでクラウドアプリケーションを開発するためのベストプラクティス | Amazon Web Services
Amazon Web Services ブログ AWS CDKでクラウドアプリケーションを開発するためのベストプラクティス この記事では、AWS Cloud Development Kit (AWS CDK) を中心とした、大規模なチームで複雑なクラウドアプリケーションの開発を組織化するための戦略について説明します。AWS CDK では、開発者や管理者は、TypeScript、Python、Java、C#などの使い慣れたプログラミング言語を使ってクラウドアプリケーションを定義することができます。アプリケーションは、Stage、Stack、Constructに整理されており、ランタイムロジック (AWS Lambda コードやコンテナ化されたサービスなど) と、Amazon Simple Storage Service (Amazon S3) バケット、Amazon Relational D
IaC化されていないリソースをdriftctlで検知する
今時の現場では、管理対象のリソースの大半はIaC(Infrastructure as a Code)化されており、 PRを契機にリソースのプロビジョニングを行うように綺麗に管理されている現場も多いかと思います。 一方で、前任のインフラ担当がリソースをIaC化せずに退職してしまったような荒れた現場や、 あるいはIaC化が浸透しきっておらず、部署によっては担当者がWebコンソールを介してリソースを作ってしまっているような現場もまだまだ存在します。 通常、そのような現場の場合、コード管理されていない野良リソースの追跡は困難を極めますが、 それを手助けするツールとして、driftctlというツールが登場しました。 driftctlとは driftctlは、IaC化されていない野良リソース——driftctlの文脈で言うところのDrift——を検知するツールです。 また、厳密には異なりますが、Ter
Pulumi Automation API でSelf-serviceなPlatformを作ってみる - Qiita
はじめに 先日、PulumiからAutomation API がリリースされました。 Pulumiはこれまでも汎用プログラミング言語で宣言的な環境構成の定義ができていました（TerraformをHCLではなく汎用プログラミング言語で書けるイメージです）が、構成定義だけでなく、ステートの管理や環境への変更適用などこれまでCLIを使って実施していたタスクもプログラム言語内で完結させて実施できるようになりました。 これによって、Pulumiで行っていた環境構成の定義から、定義した構成の実環境への適用まですべてをバックエンドサーバと統合できるようになりました。こうした機能をAPIなどを通じて公開することで、開発者や運用者が簡単に利用できるようになります（PulumiではこのユースケースをPlatform APIと言う名前で呼んでいます）。 今回これを活用して、外部からAPIや簡単なGUIを使って、
がんばらないIaCの温度感 - Qiita
この記事はWanoグループ Advent Calendar 2020１9日目の記事になります。19ったら19です。 AWSでInfrastructure as Code、やってるでしょうか。 やるにしても辛いことも多いですね。 最近やってるものの構成や困ったところをメモしておきます。 今やってる構成 現行プロダクトでは、 s3やrdsなどステートフルなものや、ライフサイクル上いろんなアプリから参照されるものは「コンポーネント目線で水平分割」(terraform) インフラという以上にアプリ寄りのコンポーネントや最悪消えてもいいものは「サービス目線で自由に垂直分割」(ツール自由) くらいでふわふわやってます。 以下のような構成です。 v2 ├── data_id │ ├── 01_emulated_resources.tf │ ├── 02_existed_resources.tf
Configuration Managementツールのポリシー定義用中間言語に関する考察 (WSA研#7予稿) - Gosuke Miyashita
概要 マネージドなコンテナ実行環境の普及に伴い、Configuration Managementツールを利用する必要がある現場は少なくなったが、Configuration Managementツール自体の必要性はまだ失われていない。また、モバイルコンピューティングやエッジコンピューティングの普及に伴い、Configuration Managememntツール自体のあり方も今後変化していくと考えられる。 本予稿では、Configuration Managemantツールの役割を整理し、Configuration Managementツールの今後のあるべき姿を検討する。それにより導きだされた、Configuration Managementツールを3層で構成する方式を提案し、その中で中心的な役割を果たすポリシー定義用中間言語について考察する。 Configuration Managementと
Announcing HashiCorp Terraform 0.14 General Availability
Sign up for freeGet started in minutes with our cloud products TerraformInfrastructure as code provisioning
Terraform開発時のDeveloper Experienceを爆上げする
はじめに1 この記事は terraform Advent Calendar 2020 2日目の記事です。 1日目は rakiさん の 2020年の terraform-jp 振り返り です！ 3日目は rakiさん の aws iam policy で s3 の bucket 制限を書く時に便利かもしれない小技 です！ はじめに2 こんにちは。みなさんterraform書いてますか？ 最近は日に日にterraformがIaCのデファクトになりつつあるように感じます。 Google Trend もちろんterraform本体の開発が活発なのも一因ですが、terraformを取り巻くecosystemの隆盛も近年普及してきた要因の一つなのかなと感じます。適切にecosystemを使いこなせば一般的なwebアプリケーションの開発時のライフサイクルと同じようなDeveloper Experienc
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
