[DevOpsプラットフォームの取り組み #7] 独自のKubernetesカスタムオペレーターを用いたCI/CDエンジン - NTT Communications Engineers' Blog
DevOpsプラットフォームの取り組みを紹介する7回目の記事です。 Qmonus Value Stream 開発チームの奥井（ @HirokiOkui ）です。 連載第7回では、Qmonus Value Streamの中核を担うコンポーネントであるAssemblyLineについて深堀りします。 第2回 および 第6回 で解説したとおり、Qmonus Value Streamでは、AssemblyLineという独自のリソースを定義してCI/CDパイプラインを構成します。 AssemblyLineは、 Tekton と同様にKubernetesのカスタムオペレーターとして実装されています。 AssemblyLineは、Tekton Pipelineを実行するワークフローエンジンとしての責務に加えて、柔軟性の高いCI/CDパイプラインを構成・実行するために必要な様々な機能を有しています。 本記事
![[DevOpsプラットフォームの取り組み #7] 独自のKubernetesカスタムオペレーターを用いたCI/CDエンジン - NTT Communications Engineers' Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/2f6ffb293f07e5c63222cfd9c762437543954b40/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2FN%2FNTTCom%2F20220916%2F20220916161541.png)
[DevOpsプラットフォームの取り組み #6] CI/CDにおけるパラメータの課題とQmonus Value Streamの取り組み - NTT Communications Engineers' Blog
DevOpsプラットフォームの取り組みを紹介する6回目の記事です。 Qmonus Value Stream 開発チームの奥井 ( @HirokiOkui ) です。 連載第6回では、パラメータを効率的に管理するためのQmonus Value Streamの取り組みについて紹介します。 第3回 で解説したとおり、Qmonus Value StreamではInfrastructure as Code（以後IaC）およびCI/CDパイプラインを記述するためにCUE言語を用いています。 CUE言語は洗練されたデータ記述言語であり、CUE言語が有する型システムやプログラマビリティにより、宣言的マニフェストを高品質かつ効率的に記述することが可能になります。 しかしながら、CUE言語を用いても改善できない領域が存在します。 それは、パラメータです。 本記事では、IaCおよびCI/CDパイプラインの構築に
![[DevOpsプラットフォームの取り組み #6] CI/CDにおけるパラメータの課題とQmonus Value Streamの取り組み - NTT Communications Engineers' Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/e1dc56cd92c697974f3d36eb41ee4779696aff8b/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2FN%2FNTTCom%2F20220824%2F20220824100559.png)
GitHub ActionsにおけるStep/Job/Workflow設計論
この記事について GitHub Actionsには、以下3つの実行単位が存在します。 Workflow Job Step パイプラインを組む中で出てくる複数個の処理を、1つの実行単位でまとめてしまうか、それとも分割するのかというのは悩むポイントかと思います。 一つのstepのrunフィールドにコマンドを詰め込む？それともstepを分けた方がいい？ 一つのJobの中のstepとして記述した方がいい？それとも別のJobに定義した方がいい？ 一つのWorkflowの中にJobをたくさん定義する？それともWorkflowを別にする？ この記事では、Workflow・Job・Stepそれぞれの性質を踏まえた上で、ベストな処理単位の選び方を考察します。 使用する環境・バージョン GitHub Actions: 2022/5/15時点での機能をもとに考察 読者に要求する前提知識 GitHub Actio
基礎からわかるDevOps #devfesta
2. 吉羽龍太郎 / Ryuzee.com ✤ アジャイル開発/DevOps/クラウドに関する 従量課金型コンサルティングサービスを提供 ✤ http://www.ryuzee.com @ryuzee 4. 時価総額ランキング 2016 2006 1. アップル (6091億ドル) 1. エクソンモービル (4470億ドル) 2. アルファベット (5434億ドル) 2. GE (3840億ドル) 3. マイクロソフト (4487億ドル) 3. マイクロソフト (2940億ドル) 4. Amazon (3969億ドル) 4. CITIグループ (2730億ドル) 5. Facebook (3683億ドル) 5. ガスプロム (3680億ドル) 5. 現在のビジネス状況 ✤ ビジネスの変化がどんどんはやくなっている ✤ VUCA => Volatility (不安定) / Uncertain
インフラの継続的デリバリー - naoyaのはてなダイアリー
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
