AWS CDK on PulumiがGAしました！CloudFormationを経由しないCDK、その使い方を少し確認してみました！ はじめに 製造ビジネステクノロジー部の佐藤智樹です。 本記事はAWS CDK Advent Calendar 2024の6日目の記事です。 今回は2024年12月2日にGAしたAWS CDK on Pulumi(以降CDK on Pulumi)について紹介します。Pulumiについては詳しい知識がないため、CDKとの関係性を調査しながら情報を共有します。 発表記事 パブリックプレビュー発表時の記事 CDK on Pulumiとは Pulumiは、Pulumi自体の記法でCDKのようにマルチクラウドのリソース構築やステート管理が可能なサービスです。これは元々CDKとは独立したものです。では、CDKはどの部分に関わるのでしょうか？GA前の記事を読むと、Pulum
この記事は、Finatextグループ Advent Calendar 2024の3日目の記事です。 はじめに ナウキャストでデータエンジニア/データプラットフォームエンジニアとして働いている@mt_musyuです。ナウキャスト社内のデータ基盤の構築や運用を行い、また社内の知見を生かしてクライアント企業様のデータ基盤の構築や運用の支援を行っています。 近年、データ利活用の推進や生成AIの利用が進む中で、データ基盤の重要性が増しています。単にデータ基盤を構築するだけでなく、増え続けるデータやユーザーを考慮した運用も求められています。そのため、データ基盤の構築や運用を効率化するために、IaC（Infrastructure as Code）の導入が重要であると考えています。もちろん、通常のシステム開発においてもIaCは重要ですが、データ基盤においては特にその重要性が際立っていると考えています。そう
はじめに 個人的な感想です。 長年AzureのインフラをIaCで開発してきましたが、最近はTerraformも覚えてきて一応以下の3つは習得できたかなと。 Azure Resource Manager Template(ARM) Bicep Terraform それぞれ構文も異なりますが、作りたいAzureリソース、設定したいリソースパラメータの指定方法が異なるだけです。 いずれしても結局はAzureインフラの設計が行えないとダメです。 それぞれの特徴などについて、私見で記しました。 各テンプレートの概要 Azure Resource Manager Template(ARM) 記述形式はjsonです。 こちらをゼロから作成するのはとても大変ですが、以下のドキュメントを読み進めると作れるようになるでしょう。 Bicep 記述形式はMicrosoftのオリジナルです。 jsonによくあるカン
OpenTofuについて調べてみた内容 SRETT #11 https://3-shake.connpass.com/event/339212/
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 生成AIが話題になる中で、最近はAWS CDKを使ってインフラを生成することにハマっています。 その過程で、 IaC（Infrastructure as Code） が生成AIによってどのように進化していけるかを考えてみました。 そこで、 IaP（Infrastructure as Prompt） という新しい言葉を生み出して、この概念をうまく説明できないかと試行錯誤してみたわけです。 本記事では、IaCとプロンプトエンジニアリングの類似点を掘り下げ、IaPの可能性や現時点での課題について一緒に考えてみましょう。 そして、現時
はじめに インフラストラクチャ・アズ・コード（IaC）の次世代技術として注目を集めているインフラストラクチャ・アズ・ランゲージ（IaL）。本記事では、IaLを活用してAWS FargateにStreamlitアプリケーションをデプロイする過程を詳細に解説します。AIによるコード生成と自然言語での要件定義を組み合わせることで、インフラ構築のプロセスがいかに簡素化されるかをご覧いただけます。 プロジェクト概要 本プロジェクトでは、ねこねこカンパニーの工場ダッシュボードをStreamlitで作成し、AWS Fargateにデプロイします。主な特徴は以下の通りです： Streamlitを使用した対話的なダッシュボード AWS FargateとECSを利用したサーバーレスデプロイ Terraformによるインフラのコード化 IPホワイトリストによるセキュアなアクセス制御 IaLによる要件定義 IaL
最近は関わる案件の多くで IaC を前提とすることが多くなってきました。 Azure においては、主に Terraform と Bicep という選択肢があると思うのですが、改めて自分なりにどちらを使うと良さそうか考えてみたので、残しておこうと思います。 1. それぞれのメリット／デメリット 「👍️」は特に良いと感じる点、「🤯」は特に辛いと感じる点です。 Terraform のメリット 👍️マルチクラウド対応: Azure だけでなく、AWS, GCP などのクラウドプロバイダに対応しているため、異なるクラウド環境で一貫した管理が可能。 大規模なエコシステム: Terraform には多くのプロバイダとモジュールが存在し、広範なコミュニティサポートがある。 成熟したツール: 長く利用されているため、ドキュメントが充実しており、企業での導入事例やベストプラクティスも多い。 プランニング
PackerBuild and manage images as code
昨今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を利用するるための足がかりをこの記事ではECS on Fargateのサービス作成とS3バケットの作成を例に挙げながら提案して
DNSレコードをTerraformで管理していたドメインがありました。(Route53) IaC(Infrastructure as Code)は当然のようになっていてこのドメインもTerraformで管理していました。 しかし運用していくにつれ今の構成に不満点も出てきてて, なんかいい感じに出来ないかな~と思っていました。 Terraformで管理しているけど, 管理するレコード数が多くなるにつれ terraform plan や terraform apply の実行に時間がかかるようになってきた CircleCI使って自動化してるからデプロイ待たないで違うことしてればいいんだけど, そこまで何か違うことできるほど時間かかるわけじゃないから結局待っちゃってストレス そもそもコード化してるけど, このドメインに関していうとプルリク作ってレビューしてapply!みたいな慎重な手順は踏む必要
これは CDK Advent Calendarの 6日目のエントリーです。 みなさんこんにちは。大村(@yktko) です。 ときどき Infrastructure as Code (IaC) を頑張った結果辛くなってしまったという話を聞いており、以前 JAWS DAYS でこんな LT をやらせていただいたことがあります。 AWS社員による怒涛のLTチャレンジ! Infrastructure as Codeに疲れたのでなんとかできないかCDKで色々やってみる このLTでは勢いで話してしまったのですが、このエントリーでコードによる管理がどうだったら良さそうなのか、自分の経験を元に整理してみます。文中に出てくるプレゼン資料はこのLTからとっています。 なお、システムの運用は状況によって適切なやり方が異なります。これが一般に通用する正しい方法だとは思っていませんが、一つの考え方だと思って読んで
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の一人です。 クラウドネイティブな
PackerBuild and manage images as code
技術 1 課の水本です。 最近 Terraform のリファクタリングを行っているのですが、ベストプラクティス迷子になっています。 HashiCorp でも明確な方針は打ち出していない為、Terraform を利用する各プロジェクトで方針を決めているのが現実のようです。 今回は私が出会ってきた問題と、それについての対応、見解を書き連ねていきます。 あくまでも私が思ったことですので、「こうしたほうがいいよ！」というネタも募集しています。 workspace 使うのか使わないのか問題 結論として、私自身は workspace という機能を知ったものの、使うことは考えませんでした。 Terraform では workspace という個別のエリアを設けることが可能で、これを prod や staging と命名し作成しておくと、完全に環境を分離できるというメリットがあります。 ただしデメリットと
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を呼び出し可能、クラウドのアップデートに即時対応など コードを用いてクラウドをはじめとする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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く