「Pulumi Stack」とは ー Pulumiによるマルチステージ環境の構築方法
第3回となる今回は、Pulumi Stackの概要について解説し、複数Stackのデプロイについてハンズオンを実施していきます。 はじめに 前回は、Pulumiのチュートリアルを通して実際にAWSリソースを作成し、Pulumiの基本的な使い方について解説しました。今回は、前回でも少し触れたPulumiのStackについて、もう少し深掘りして概要/メリットや活用方法を解説していきます。 なお、後半のハンズオンではdev環境や本番環境など、リリース段階に応じた複数の環境をPulumi Stackで実際に構築し、Stackの理解を深めていきます。 Pulumi Stackについて Stackの概要 Stackとは、異なる環境やアプリケーションごとにインフラストラクチャをデプロイするための機能であり、Pulumi Programから生成されるインスタンスです。例えば、1つのPulumi Progr
SecretもPulumiで使いこなしたい! PulumiのSecurityを試してみよう
第4回となる今回は、PulumiのSecurityについて解説し、ハンズオンではPulumiによる暗号化処理を行い、AWS SecretManagerを利用したRDS接続する流れを実践していきます。 はじめに 前回は、実際にマルチステージ環境のStackを構築して、Stackの概要や活用のメリットについて解説していきました。今回は、第1回でも少し触れたPulumiのArchitectureをおさらいしつつ、PulumiにおけるSecurityについて解説していきます。 なお記事後半のハンズオンでは、Securityに関連してAWS RDS(MySQL)接続のための認証情報についてPulumiによる暗号化処理を行い、AWS SecretManagerを利用してセキュアにRDS接続する流れを実践していきます。 PulumiのArchitecture Pulumiは大まかに2種類のArchite
Policy as Codeでインフラのコンプライアンスを自動実現! 「Pulumi CrossGuard」を活用してみよう
第5回となる今回は、Policy as Codeの概要を解説し、「Pulumi CrossGuard」を利用してPulumiでリソースを作成する際のポリシーチェック を行うハンズオンを実践していきます。 はじめに 前回はPulumiのSecurityについて解説しました。今回は、前回で少し触れたPulumi Policy as Codeのポリシーエンジンとなる「Pulumi CrossGuard」について解説していきます。後半のハンズオンでは、「Pulumi CrossGuard」を利用して実際にPulumiでリソースを作成する際のポリシーチェックの様子を確認していきます。 Policy as Codeについて そもそも、Policy as Codeとはなんでしょうか? まず、その概要を少しおさらいします。 Policy as Codeの概要 一般的に、Policy as Code(PaC
エッジでKubernetesを実装する新しいプラットフォームをIntelとSpectro Cloudが紹介
KubeCon Europe 2023の共催イベントEdge Dayから、IntelとSpectro Cloudが実装した新しいプラットフォームを紹介する。 Kubernetesがサーバーサイドのコンテナオーケストレーションだとすれば、若干取り残されている感があるのが、エッジのプラットフォームだろう。エッジで使われるOS、プラットフォームは物理的に小さなフォームファクターで、メモリーやプロセッサなどのリソースに制限がある中でさまざまな使われ方が存在する。オープンソースソフトウェアだけでもLinux Foundation配下のYocto、LF Edgeが推進するAkraino、EdgeX Foundry、車載向けのAGL（Automotive Grade Linux）、医療やエネルギーなどセキュリティが重視される領域を想定したELISAから、コマーシャルベースだとRed Hatが発表したRe
CI/CD Conference 2023から、GMOペパボのSREがVM/Kubernetes混在環境でのCI/CDについて解説
CI/CD Conference 2023から、GMOペパボのSREが仮想マシンとKubernetesが混在する環境におけるCI/CDの課題と解決策を解説したセッションを紹介する。 CI/CDに特化したカンファレンスCI/CD Conference 2023から、GMOペパボ株式会社のSREが解説する仮想マシンとKubernetesが混在した環境でのCI/CDの改善について解説するセッションを紹介する。プレゼンテーションを担当したのは2021年にGMOペパボに中途で入社したSREの渡部龍一氏だ。 ●動画：インフラCI/CDの継続的改善の道のり セッション開始から約8分は自己紹介と自社紹介に使われており、実質的なシステムの解説は以下のスライドから始まった。今回はスライドが別資料として公開されており、そこから引用している。 ●参考（発表資料）：インフラCI/CD継続的改善の道のり
「KubeCon NA 2022」から、サイドカーレスを実装したサービスメッシュのIstioのセッションを紹介
「KubeCon + CloudNativeCon NA 2022」から、サービスメッシュのIstioのセッションを紹介する。IstioはGoogle、IBM、Lyftが初期の開発を行い、その後CiscoやRed Hat、Solo.ioなども加わって開発を継続しているサービスメッシュのオープンソースソフトウェアだ。2022年9月28日にCNCF配下のインキュベーションプロジェクトとして採用された。実は2020年にGoogleはOpen Usage Commonsというトレードマークの管理を行う非営利団体を立ち上げ、Istioを寄贈した。これは「Istioのガバナンスを中立的な組織に移譲して欲しい」というオープンソースコミュニティからは非難されることとなった。GoogleがOpen Usage Commonsを立ち上げたことに関しては以下の記事を参照されたい。 ●参考：GoogleがIsti
Microsoftがリードするモダンな分散システム用ランタイムDaprとは？
MicrosoftはCNCF（Cloud Native Computing Foundation）が主催するWebinarで、クラウドネイティブなシステムにおいて分散処理を実装するランタイムであるDaprを解説するセッションを実施した。CNCFのWebinarページには、CNCFにホストされている多数のプロジェクトのセッションだけではなくCNCFのメンバーによる技術解説が公開されている。今回紹介するセッションは2020年10月1日に公開されたもので、CNCFのプラチナムメンバーであるMicrosoftがコンテンツを提供したものになる。 参考：Dapr, Lego for microservices セッションのタイトルは「Dapr, Lego for Microservices」というもので、マイクロサービスを構築する際にランタイムとして機能するDaprの最新情報を紹介する内容となった。
分散型アプリの開発と運用を分離するOAMとDapr、そしてKubernetes上の実装であるRudrとは？
分散型アプリの開発と運用を分離するOAMとDapr、そしてKubernetes上の実装であるRudrとは？ クラウドネイティブなシステムの理想形の一つは、オンプレミスのプラットフォームであったとしてもAWSやMicrosoft Azure、GCPのように柔軟でスケールアウト可能なインフラストラクチャーの上に分散型のアプリケーションが稼働することだ。 しかし実際には仮想マシンからコンテナベースのインフラストラクチャーに移行し、アプリケーションの実行単位がコンテナになったとしても、アプリケーション自体が分散型になることはそれほど進んでいない。これはモノリシックなアプリケーションを分散型にリアーキテクチャーすることの難しさの現れであろう。また新規のアプリケーションにおいても、デジタルトランスフォーメーション（DX）を促すベンダーサイドの掛け声の割には導入が進んでいないというのが現実だろう。 この
Dockerの管理・監視ツール(1)
ITシステムが地方に散在する場合、Dockerに精通した管理者が不在であることも少なくありません。Dockerに詳しくない人でも、効率よく、かつ、ミスなく管理するためには、GUI管理・監視ツールの導入が必要になります。特に、近年では、クラウド基盤の導入が進み、IT部門だけでなく、ユーザー部門などが、セルフサービスポータルのダッシュボードのWebユーザーインタフェースなどを使って、みずからサービスを利用することも増えてきました。現在は、OpenStackなどに代表されるクラウド基盤ソフトウェアは、Linuxのハイパーバイザー型仮想化技術であるKVMをベースとした仮想マシン（インスタンス）の管理が中心ですが、Dockerにおいても、クラウド基盤に見られるセルフサービスポータルのような、直観的で分かりやすい管理画面が求められています。2015年9月中旬現在、Dockerコンテナを簡単なGUIで操
詳解KubernetesにおけるPersistentVolume
はじめに コンテナはデータを持つアプリケーション(ステートフルアプリケーション)には不向きと言われてきました。しかし、Kubernetesの進化に伴い、ステートフルアプリケーションも動作できるようになってきました。 そこで本記事では、ステートフルアプリケーションをKubernetesで動作させるために重要となるストレージについて解説します。 ストレージのモデル Kubernetesは、データを永続化するためのストレージを抽象度の高いモデルで表現しています。これにより、ユーザはストレージの詳細を知らなくても、Pod内のコンテナにボリュームを割り当てて使うことができます。 PersistentVolumeClaim, PersistentVolume, StorageClass Kubernetesではストレージの基本モデルとして、次の3つのリソースがあります。 PersistnetVolum
Pythonで作られた便利なコマンドラインツール MySQL Utilities
MySQL Utilitiesならではの注意点 MySQL Utilitiesは従来のコマンドラインツール群とは違い、以下のような記述で接続先を指定します。 これは、従来のコマンドラインツール群が主に1つのMySQLサーバーを対象として動作するものなのに対して、MySQL Utilitiesは2つ以上のMySQLサーバーを対象として動作するものが多いため、このような記法になっています。 [MySQL Utilitiesの記法] --server=ユーザ名:パスワード@ホスト名:ポート番号 [MySQL コマンドラインツール群の記法] --user=ユーザ名 --password=パスワード --host=ホスト名 --port=ポート番号 なおWindows環境ではローカルホストとしてlocalhostと127.0.0.1のどちらを指定しても同じですが、LinuxやUNIXではホスト名に対
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
