昨日はトランクベース開発とデプロイについて書いたので bufferings.hatenablog.com この勢いで GitOps とデプロイも書いてしまうー。先に言っておくと、自分は GitOps の経験はない。でも、よさそうだなぁと思う手法なので、機会があれば挑戦してみたい気持ち GitOps? GitOps は2017年に Weaveworks の Alexis によって提唱された手法で、Kubernetes を対象としている Guide To GitOps Git のリポジトリーに入れてある設定ファイルを Single Source of Truth として、Kubernetes のクラスター管理とアプリケーションデリバリーを行う。上記の記事には次の4つの原則が書かれている システム全体が宣言的に記述されていること 正規の望ましいシステムの状態が Git でバージョン管理されている
いわゆる退職エントリってやつですね、せっかくなので。とはいえ技術書典で文章を書くことに飽きたので簡単にしか書きません。 まだ有給消化中ですが1年半勤めたさくらインターネットを10月で退職し、大阪大学大学院情報科学研究科で博士後期課程に進学します。出戻りみたいな感じです。東京から大阪に移りました。 やっていたこと さくらインターネットには修士新卒で入社し、主に2つのプロジェクトを担当していました。 1つ目のメインで稼働していたプロジェクトですが、こちらはまだリリースされていないので詳細は伏せます。レイヤ的には要件定義・全体設計・DevOps・実際のアプリ開発といったところを担当していました (溢れ出るふるすたっく感！)。最近k8sのイベントや執筆をすることが多かったですが、主にこのプロジェクトで活かしてきたものになります。技術スタックの中でもgolang・k8s・gitops辺りを中心的に扱
2021年に注目すべきCNCFの5つのテクノロジーを「Kubernetes Meetup Tokyo」のセッション記事から解説する
2021年に注目すべきCNCFの5つのテクノロジーを「Kubernetes Meetup Tokyo」のセッション記事から解説する はじめに Kubernetes Meetup Tokyoの懇親会用に話のネタとしてメモを残す。 2021年に注目すべきCNCFの5つのテクノロジーとは？ KubeConNA(2020)最終日のkeynote session、Keynote: Predictions from the Technical Oversight Committee (TOC) - Liz Rice, CNCF TOC Chairで、CNCFのTOC(技術統括委員会)の委員長を務めるLiz Riceさんが、CNCFの2021年の技術的展望として紹介した5つの技術要素である。(順不同) カオスエンジニアリング エッジコンピューティングとしてのKubernetes サービスメッシュ Web
AWS OSS製の高速Cluster Autoscaler Karpenter | Recruit Tech Blog
今回の記事はリクルートアドベントカレンダー2021の10日目の記事です。 こんにちは。スタディサプリ ENGLISH SREグループの木村です。 re:Invent2021で AWS OSS製のCluster Autoscaler KarpenterがProduction readyになったことをがアナウンスされました。 『スタディサプリENGLISH』では基盤にkubernetesを採用しており、今回導入ができないか検証をした記録です。 1)現在はauto scalingにはspotを利用しており別途記事になっているので興味があればこちらも参照ください Karpenterとは？ 公式の説明では下記のように説明されています。 Karpenter automatically launches just the right compute resources to handle your cl
人に説明するのがスムーズにできなさそうなので、理論武装というか順序立てて話すためにこの記事をまとめる。 対象 ブラウザから利用するマルチプラットフォーム向けウェブアプリケーションの開発 モバイルのネイティブアプリ開発は含まない（知らないので） 利用言語はJava, JavaScript/TypeScriptを想定するが、特に言語に依存しない認識 開発経験はあるが、情報や経験が少なくて「よりよいプロダクト開発」の理想が描けない方への一助として作成 TL;DR 状況やベストプラクティスが目まぐるしく変わる現代において、すぐに変化できるソフトウェアを保つこと・ヒトの手をできるだけ空けることが重要。 かつてIaaSがAPIを提供し環境管理の多くを自動化したように、各種サービスがAPIやWebhookを通じてDevelopment Workflowの多くを自動化してきている。 多くの視点や知見を活か
CIOpsからGitOpsへ。Flux2でマイクロサービスのデプロイを爆速にした話 - ZOZO TECH BLOG
はじめに こんにちは。SRE部の巣立（@ksudate）です。 ZOZOTOWNのマイクロサービス基盤では、GitHub Actionsを利用したCDパイプラインを構築しています。しかし、管理するマイクロサービスが増えるにつれて運用負荷が高まりつつありました。 本記事では、ZOZOTOWNのマイクロサービス基盤のCDパイプラインが抱える課題と、それらをFlux2でどのように解決したのかを紹介します。また、Flux2の導入にあたり工夫したポイントを紹介します。 目次 はじめに 目次 Flux2の導入背景 マイクロサービス基盤のCI/CDパイプラインが抱える課題とこれまでの対策 Flux2とは？ Flux2によるGitOpsの実現 Flux2の導入で工夫したポイント Flux2の管理 GitRepositoryとKustomizationの管理 Flux2によるkustomize build
[レポート] AWS Well-Architected best practices for DevOps on AWS #DOP207 #reinvent | DevelopersIO
[レポート] AWS Well-Architected best practices for DevOps on AWS #DOP207 #reinvent こんにちは、つくぼし(tsukuboshi0755)です! re:Invent2022のセッション AWS Well-Architected best practices for DevOps on AWS を視聴したので、レポートしたいと思います。 セッションの概要 In this session, learn about all of the components required to align your DevOps practices to the pillars of the AWS Well-Architected Framework. Review organization adoption, development
![[レポート] AWS Well-Architected best practices for DevOps on AWS #DOP207 #reinvent | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/e4cafbaaf61ae0e896e83da659ab2ddaa2d28c88/height=288;version=1;width=512/https%3A%2F%2Fd1tlzifd8jdoy4.cloudfront.net%2Fwp-content%2Fuploads%2F2022%2F11%2Feyecatch_reinvent2022_session-report.png)
執行役員 VP of Engineering 兼技術部長の @hsbt です。前回のエントリから、モンスターハンターストーリーズ2の発売の前に執筆の出番がやってきてしまいましたが、今はアサシンクリードヴァルハラでスルーしていた宝箱やクエストなどを消化しています。戦国無双5も面白そうなので気になっています。 HR 統括部門の @achamixx から「ペパボには採用目的という強いコンテンツがあるので 2021 は採用目的をもう一度やりましょう」という提案を受けて、予告編として私の管掌範囲である技術部の「現状」、「これから」、「仲間になってほしい方に求めること」の三つについて紹介しようと思います。 技術部の現状 最初に技術部という組織の位置付けについてご紹介します。GMO ペパボ(以下、ペパボ)には、事業部門として ホスティング、EC、minne、SUZURIの4つがあり、管理部門として、経営
ABEJA Insight for Retailの技術スタックを公開します (2021年10月版） - ABEJA Tech Blog
初めに 会社・事業紹介 ABEJA Insight for Retailについて 技術スタック 全体アーキテクチャ図 ① 映像録画・解析システム ②データ基盤部分 ③ Webダッシュボード その他 (全体共通部分) 一緒に働く仲間を募集中！ 最後に 初めに こんにちわ。大田黒（おおたぐろ）です。暑い日が落ち着いてきて、秋(冬？）が来たなぁと感じるこの頃です。皆様いかがおすごしでしょうか。前回の「ABEJAの技術スタックを公開します (2019年11月版)」が公開されてからしばらく経ちました。 引き続きエンジニアの方とお話させていただく中で、 「ABEJAってよく聞くけど...実際どんなことやってるのかよくわからない」 「AIのお硬いSIerって感じなんでしょ？」 「社内は機械学習エンジニアばっかりなんでしょ...??」 といったご質問をいただくことが多いです。 今回の記事では､最新の会社や
技術とノウハウを武器に、膨大かつ複雑なデータの「検索」「分析」「可視化」といった課題を解決するフォルシア株式会社が「FORCIA Meetup #2」を開催しました。2回目の今回のテーマは「2020年度にエンジニアが取り組んだこと」。六車氏は、CI/CDの整備について発表しました。 管理ツールとして「GitLab」CI/CDツールとして「GitLab CI/CDツール」を利用 六車光貴氏（以下、六車）：六車が『エンジニア1年目の貢献：CI整備を中心に』というタイトルで発表します。まず自己紹介です。六車光貴と申します。ちょっと変わった名前ですが、四国の香川県出身で、香川県だと小学校のクラスに1人はいる名前です。 フォルシアには2020年4月に新卒で入社して、ソフトウェアエンジニアとして働いています。主に大手旅行代理店のサイトの構築をTypeScript、Node.js、React、Next、
はじめに# この記事は，HERP における Web フロントエンド開発の概観を，世間の開発者に——特に潜在的・顕在的な候補者の方に——知ってもらうことを目的として書かれた．HERP では現在 Web フロントエンドエンジニアを積極的に募集しているが，仮に入社したとしてどのような仕事をすることになるかのイメージが付いた方が，検討の候補に入れてもらいやすいのではないかという目論見による．また，採用している技術スタックにも珍しいものがあるため，単純に読み物として楽しめるかもしれない．なお，開発の実情について知ってもらうのが目的であり，実装の良し悪しについて議論することは目的としていない． HERP でのアプリケーション開発# B2B SaaS として，主に IT スタートアップ企業向けの，採用管理システムおよびタレントプールシステムを開発・提供している． そもそもプロダクトを通じて何を実現したい
Rationale The entire premise behind GitOps is to use Git as the source of truth for infrastructure and application configuration, taking advantage of Git workflows, while at the same time, having automation that realizes the configurations described in Git repositories (GitOps operators when we are deploying to Kubernetes). That said, both infrastructure configuration and application configuration
SREエンジニアが目指すGKE共通デプロイ基盤の完成形 - ぐるなびをちょっと良くするエンジニアブログ
こんにちは。開発部門 開発部 Data AI Strategyセクション データ基盤 Unitの小野です。 2020年8月に入社してから早3年。SREエンジニアとして、日々業務改善に励んでいます。 ここ一年ほど、DAOという組織改善プロジェクトを推進していく中で、Google Kubernetes Engine (GKE)を使ったGKE共通デプロイ基盤の整備も進めてきました。 ※ DAOについての詳細はSREエンジニアが組織改善プロジェクトを立ち上げてみたを参照ください SREエンジニアの責務の一つは、プロダクトのリリースサイクルを極限まで短くし、次々と新しいサービスを世の中にリリースすることです。ChatGPTのような誰でも簡単に扱えるAIモデルが誕生したことで、プロダクト開発競争は今後ますます激しくなっていくと予想しており、SREエンジニアの責務の重要性をヒシヒシと感じています。 そう
こちらはLivesense アドベントカレンダー 2020 およびKubernetes3 アドベントカレンダー1日目の記事です。 こんにちは、転職会議のSREのかたいなかです。 転職会議では2020年の一年間をかけてインフラ基盤をECSからEKSに移行してきました。 この記事では構築したEKS基盤やECSからの移行の中で工夫した点を紹介します。 なぜEKS移行？ 古くなっていたECS基盤を刷新する上で、ECSで再度作り直すのではなくEKSを選んだのは主に以下のような理由です。 IaCを更に推し進めGitOpsの考えを採用し、開発者がSREにレビュー以外で依存することなく主体的にインフラを変更できる状態を作るため ArgoやIstioといったKubernetesネイティブに開発されているツールを採用することでの恩恵を将来的に受けられるようにするため 純粋な技術的興味 採用を決めた当時は技術的
こんにちは、アソビュー！SREチームのkirimaruです。 コロナも少し落ち着き、皆さんもGWは大いに満喫していたのではないでしょうか。 残念ながら僕は本を読んで引きこもっていましたが......。 以前「アソビュー！がECSではなくEKSを選んだ理由」という内容でランサーズさんとのイベントでお話させていただきました。 speakerdeck.com 今回はこの時から約2年、アソビュー！がEKSとどう向き合ってきたのか、どう向き合っていくのかを採用している技術とともにご紹介できればと思います。 Intro 前述のイベントでは「大量のAWSアカウントとECSクラスターの管理が辛いから、整理してEKSに統合していくぞ！」とお話させていただきました。このイベントは2020年ですが、2019年に試験的にEKSを導入し、2020年に本格移行の意思決定を行っています。SREチームはまだまだ人数が少な
ぐるなび×GitLab×Rancher ~Deep Dive~ - ぐるなびをちょっと良くするエンジニアブログ
はじめまして。ぐるなびでサーバインフラエンジニアを担当している遠藤です。かれこれ8年以上在籍しています。 この記事では「GitLabとRancherで何ができるか」「ぐるなびではどう使っているか」 について書こうと思います。 ひっくるめて「ぐるなび×GitLab×Rancher」とタイトルを付けました。実は「Rancher Meetup Tokyo #13 (GitLab x Rancher特集)」というイベントで、全く同じタイトルで登壇させていただいたことがあります（そのときの資料はこちらで公開しています）が、今回の内容はこのブログのタイトルの通り、その内容を深堀りしたものになっています。 GitLabやRancherについてある程度ご存知の方は「GitLabとRancherの連携」からお読みいただいても問題ありません。内容は以下になります。 GitLabについて GitLabとは ぐる
調査会社のガートナージャパンは、「日本における未来志向型インフラ・テクノロジのハイプ・サイクル：2023年」を発表しました。 ガートナーのハイプサイクルは、技術の登場から安定までを5つのステージに分けて説明したものです。5つのステージは、「黎明期」から始まり、「『過度な期待』のピーク期」「幻滅期」「啓発期」「生産性の安定期」まで。この途中で消えていく技術もあります。 米ガートナーはほぼ同時に「先進テクノロジーのハイプサイクル2023年」を発表しています。 こちらは別記事で紹介していますので、ぜひ合わせてご覧ください。 参考：米ガートナー「先進テクノロジーのハイプサイクル2023年」を発表。GitOpsは黎明期、生成的AIとクラウドネイティブは過度な期待のピーク さて、下記がガートナージャパンが発表した「日本における未来指向型インフラ・テクノロジのハイプ・サイクル：2023年」の図から、「黎
リクルートマーケティングパートナーズにおけるAmazon EKSとAWS App Meshを使った基盤安定性向上とGitOpsへの挑戦 | Amazon Web Services
Amazon Web Services ブログ リクルートマーケティングパートナーズにおけるAmazon EKSとAWS App Meshを使った基盤安定性向上とGitOpsへの挑戦 本番環境でコンテナを利用したワークロードを構築する場合、ほとんどのケースでコンテナオーケストレーションのテクノロジが導入されます。AWS では、Amazon Elastic Container Service (Amazon ECS) や Amazon Elastic Kubernetes Service (Amazon EKS)といったコンテナオーケストレーションに関するサービスを提供しています。 コンテナオーケストレーターの選定においては、各オーケストレーターの持つ機能や思想を理解することが重要です。Amazon ECS は、他の AWS サービスとシームレスに組み合わせることが可能であり、Amazon
KubeCon + CloudNativeCon North America 2022参加レポート〜3年ぶりのアメリカ現地開催の様子とセッション紹介〜 - ZOZO TECH BLOG
こんにちは。計測システム部SREブロックの西郷です。 10月24日から10月28日にかけてKubeCon + CloudNativeCon North America 2022（以下、KubeCon）が行われました。今回弊社からはWEARやZOZOTOWNのマイクロサービス基盤、計測システムに関わるメンバー7名で参加しました。 本記事では現地の様子や弊社エンジニアが気になったセッションについてレポートしていきます。 目次 目次 3年ぶりにアメリカでの現地開催となったKubeCon現況 参加メンバーによるセッション紹介 Istio Today and Tomorrow: Sidecars and Beyond Cloud Governance With Infrastructure As Code (IaC) With Kyverno And Crossplane - Dolis Sharm
広告技術部の yamayu です。 ホグワーツレガシーが気になっているのですがまだ手を出せていません。 映画はファンタビ以外は全部見ており、原作は 7 巻の上巻まで読んでいるため楽しめそうとは思っています。 さて、弊社ではこれまで CI/CD ツールとして CircleCI をメインに利用していたのですが、最近は GitHub Actions でも同等の機能が提供されるようになりつつあり、また GitHub の他の機能との連携が容易である等の理由から徐々に切り替えていくような動きがあります。 広告技術部で管理しているリポジトリも少しずつ GitHub Actions への移行を進めており、その中で CI/CD のプロセスの見直しを行いました。 結果として、CI の実行時間を大幅に短縮することができたので、今回はそのことについて書いていきます。 長い重い多いテスト テストの並列化 マルチノー
Argo CD Resource Hookを活用したKubernetes環境での負荷試験自動化の取り組み - ZOZO TECH BLOG
はじめに こんにちは、計測プラットフォーム開発本部SREブロックの渡辺です。普段はZOZOMATやZOZOGLASSなどの計測技術に関わるシステムの開発、運用に携わっています。 先日私達のチームでは、リリースフローにステージング環境での負荷試験を自動化する取り組みを行いました。今回説明する「負荷試験の自動化」が何を表すのかを定義すると、ここではステージング環境のアプリケーションバージョンを変更した際に、人の手を介さずに負荷試験が行われることを指します。 Kubernetes環境における負荷試験の自動化を検討している方は是非参考にしてください。 目次 はじめに 目次 負荷試験を自動化する前の課題 負荷試験のシナリオ設計 目的設定 現状調査 目標値設定 シナリオ設計 負荷試験を自動化する取り組み 構成 処理の流れ シナリオに沿ったリクエストを送る 実行結果をS3に保存してSlackに通知する
本稿について 2019年11月、GitHub上で利用できる無料のワークフローツールのGitHub Actionsが正式にリリースされました。1 これを使って、CI/CDなどの処理を自動化することができます。 本稿では、GitHub ActionsでTerraformを実行し、Google Cloud Platformの構成管理を行う方法を紹介します。 また、GitOpsによるインフラCI/CDの作業フローも紹介します。 昨日、Bitbucket PipelinesでGCPに対してTerraformでインフラCI/CDする - Qiitaという記事を書きましたが、そのGitHub Actions版となります。 共通する内容が多いので、以降ではその記事を「Bitbucke Pipelines版」として参照させて頂きます。 更新履歴 20200504 .github/workflows/terr
All In One CI/CD including everything you need to start exploring Kubernetes Multi-cluster GitOps, Tekton pipelines, Secrets management, Pull Request ChatOps and Preview Environments
Kubernetes as a platform vs. Kubernetes as an API | Amazon Web Services
Amazon Web Services ブログ Kubernetes as a platform vs. Kubernetes as an API はじめに Kubernetes とは何ですか？私はこの技術に初期から取り組んできましたが、8 年経っても、この問いにハッキリと答えられません。Kubernetes をコンテナオーケストレーターとして定義する人もいますが、その定義は果たして、Kubernetes を正しく表現できていると言えるでしょうか。私はそう思いません。この記事では、Kubernetes について、従来の考え方にとらわれない考え方や、技術の伸びしろを探ってみたいと思います。 Amazon Elastic Kubernetes Service (Amazon EKS) は、お客さまに代わって、Kubernetes クラスターを運用をする AWS のマネージドサービスであり、非常
こんにちは、食べログシステム本部長の京和です。 今年の4月から本部長になりました。さらに4月に娘が生まれました 本エントリでは食べログで1年を通じて取り組んだ、大規模なレガシーシステムの段階的な改善について紹介します。[翻訳] Shopifyにおけるモジュラモノリスへの移行 に続いて2記事目のアドベントカレンダーになります。 どのように段階的に進めるか 食べログは今年で15年目のサービスで、Railsになってからは13年が経過しています。これだけ歴史があればあちこちにガタが来ているのは当然で、無数にある課題に対してどこからどのように取り組んでいくかを最初に決める必要がありました。 まず最初の前提として以下のように考えました。 既存のビジネスや開発を止めるような悪影響を与えない。むしろなるべく早くポジティブな影響を与えていきたい。 これだけ歴史のあるシステムを改善していくのは長い時間がかかる
あえて手動アップグレードを選ぶ〜マネージドサービス(GKE)で手作業による対応をした話〜 - MonotaRO Tech Blog
こんにちは。データ基盤グループ データエンジニアリングチームの宮口です。 この記事ではGoogle Cloud Platform（以下、GCP）のサービスの1つであるGoogle Kubernetes Engine（以下、GKE）のクラスタを手動アップグレードした話を紹介します。 私が所属するデータエンジニアリングチームでは、社内システムに保存されたデータをGCPのBigQueryにニアリアルタイムで同期するシステムや、BigQueryに保存されている大容量のデータを低レイテンシなAPIとして提供するシステムなど、モノタロウのビジネスを裏側で支えるシステムの管理を行っています。それらのシステムは全てのコンポーネントをコンテナ化しており、その実行環境としてGKEを採用しています。 また、それとは別に社内でGKE共通環境と呼んでいる、マルチテナント方式のクラスタによるアプリケーション実行基盤を
Kubernetes development is not one-size-fits-all. Maybe you’re learning Kubernetes with Minikube on your local machine; maybe you’re part of a large organization with many clusters; maybe your cluster is an on-prem lab, or lives in the cloud. But whether you’re a cluster operator managing policies, an app developer test-driving a new service, or a data scientist running Kubeflow, chances are you ar
書評「Kubernetes完全ガイド」Kubernetesを学ぶ全ての人にオススメしたい ｜ DevelopersIO
「Kubernetes学ぼう！学びたい… なんかどこから学べば良いのかぜんぜんわからん…」 アプリケーション実装環境として、今や猫も杓子もKubernetesのこの時代。エンジニアとしてこれから学んでみようという方も多いと思います。 クラスメソッドでも「Kubernetesモクモク勉強会」を開催したりキャッチアップに励んでいますが、まじで学習コスト高杉くんだと思うんですよ。k8s。ホンマに。これ簡単とかいう人いたら、絶対信用したらあかん。 そんな敷居が高いKubernetesですが、モクモク勉強会でも推薦図書としていた「Kubernetes完全ガイド」が、「なにか本買って学ぶなら、これしかありえないでしょう」というぐらいの素晴らしい書籍だったので、ここにオススメさせていただきます。 （祭） ∧ ∧ Y ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉 k8s ﾏﾂﾘﾀﾞﾜｯｼｮｲ |_|＿|
はじめに 最近読んだ鎌倉時代の歌人、鴨長明の『方丈記』にも ゆく河の流れは絶えずして、しかももとの水にあらず。 とありますが、私たちのソフトウェアも然りです。 毎日更新され、デプロイされ、時に不可逆に破壊され。そして、ちぐはぐな形に落ち着くまで絶えず変更されているように感じます。 そのようなことにならないためにもOpsやCDについて注目しています。 本記事 本記事はKubernetes Advent Calendarの15日目の記事になっています。 コメントや間違いなどがあればDMやリプを軽く飛ばしてもらえると嬉しいです。 今回は、GitOpsを実現するためのツールとしてArgo CDが注目を集めているので、GitOpsについて考えていこうと思っています。 また今回はたまたまArgo CDを使ってみますが、だいたいのGitOpsに導入しやすいソフトウェアは、似たような構成なので、体系的に学
こんにちは。主にBUYMAの検索周りを担当しているエンジニアの伊藤です。 BUYMAではSolrを利用した検索システムがいくつかあります。 BUYMAの検索というと検索ボリュームが一番大きな商品検索を想像されると思いますが、 今回はデータボリュームが一番大きい検索システムをターゲットとして、インフラ周りを含め全面的にシステムの刷新を行いました。 ここでは、 既存の検索システムがどういったものだったのか なぜシステム更改が必要だったのか(どういう課題があったのか) 更改後の検索システムはどういったものか 今後の課題について 等々についてご紹介したいと思います。 既存の検索システムについて 既存の検索システムは下記の通り、シンプルという点ではとても素晴らしいものでした。 ただし下記のような問題を抱えている状況でした。 スケールアウトしない構成である スケールアップの限界 Solrのバージョンが
ECS Scheduled Taskの管理をecscheduleでGitOps化しました - コネヒト開発者ブログ
こんにちは。コネヒトのテクノロジー推進グループでインフラエンジニアをしている laughk です。 今回は定期実行バッチで利用しているECS Schedule Taskの管理に Songmu/ecschedule を導入し、GitOps化した話をまとめます。 サマリ ecscheduleを導入する前の定期実行バッチの管理状況と課題 技術選定 - ecshceduleを選定した理由 導入プロセス GitOps化 導入後どうなったか ecscheduleを導入する前の定期実行バッチの管理状況と課題 コネヒトでは提供するサービスのWeb基盤にAmazon ECSをフル活用しており、定期実行バッチにおいてもECS Scheduled Taskを利用しています。ECS Scheduled TaskはECS Taskを cron のように定期実行でき、とても便利なものです。一方でその管理においては利用
お疲れさまです。SREの西田和史(@k_bigwheel)です。 僕が所属するDX事業本部の開発基盤グループは主にインフラが安定して高いパフォーマンスで動くことに責務を持っています。 今DX事業本部には3つの事業部があり、その中ではイエウール、ヌリカエ、ケアスル介護などのサービスを展開していますので、僕らはそれらのだいたい10サービス前後のインフラを日々増築・改善しています。 僕がSpeeeにジョインしたのが3年前の2019年11月なのですが、それからDX事業本部のインフラは様々なことが進化しました。3年前から変わらず残っているインフラコンポーネントは永続化層1ぐらいといえる程です。ここではその差分を振り返ってこんな良いインフラになったぞ！という部分を書いていきたいと思います。 レガシーインフラの脱却 いきなりですが、3年前に使っていたツール・サービスと今使っているツール・サービスの対応表
DevOpsをさらに推し進めた「GitOps」という開発手法が、KubeCon＋CloudNativeConが紹介された。 KubeCon＋CloudNativeConではKubeflowやIstioなどの多くのプロジェクトが紹介され、まるでKubernetesのエコシステム展覧会と言ってもいいほどだ。その中から今回は、WeaveworksのCEO、Alexis Richardson氏が提唱するGitOpsについて紹介したい。Richardson氏は、Cloud Native Computing Foundation（以下、CNCF）のTechnical Oversight Committeeのチェアも務めている人物だ。 Richardson氏は、クラウドによってDevOpsへの流れが生じたと語り、その先にあるのは「Push Code, Not Container」とあるように開発者が「コ
【転職会議】ArgoCDで実現するストレスフリーな新GitOps基盤 - LIVESENSE ENGINEER BLOG
こんにちは、かたいなかです。 最近、転職会議のCI/CD基盤をFluxベースのものからArgoCDベースのものに式年遷宮しました。今回の記事では、新しいArgoCDでのCI/CD基盤について、作り直しに至った経緯や改善点をご紹介します。 ArgoCD移行に至った経緯 転職会議では、以前の記事でも紹介したFluxというGitOpsのツールを使用してGitOpsを実現していました。 made.livesense.co.jp しかし、その後FluxからFlux2への移行が公式から推奨されるようになった後も、Flux2やArgoCD Image Updaterへの移行ができない状態が長く続いていました。 また、現行のフローでも以下のような大きな問題点を抱えていました。 ロールバックできない問題 チャットボットが老朽化 Weave Cloudがサービス終了 以下でそれぞれ説明します。 ロールバックで
VMware Tanzu Application Catalog (Applications Tutorials) Documentation
VMware Tanzu Application Catalog (Applications Tutorials) Documentation This section provides information about how to use OSS applications available via VMware Tanzu Application Catalog. Create Your First Helm Chart Best practices writing a Dockerfile Best Practices for Creating Production-Ready Helm charts Running non-root containers on Openshift Work With Non-Root Containers for Bitnami Applica
Yahoo! JAPAN MeetUp #8 （インフラ技術カンファレンス）セッション④
わかる！metadata.managedFields / Kubernetes Meetup Tokyo 48 近頃 Server-Side Apply (SSA) の利用が広がっています。GitOps ツールである Flux2 は v0.18.0 でマニフェストの適用に SSA を使用するようになりました。そこで重要になってくるのが metadata.managedFields です。 このセッションでは、kubectl v1.21 まで kubectl get -o yaml で表示されていてめっちゃ邪魔だった metadata.managedFields が何のために存在しているのか紹介します。また SSA によりオブジェクトのフィールドを削除したはずが実際には削除されていないなんてこともおきます。なぜそんなことが発生するのか、またその状態をどのように解決するかも紹介します。 イベン
Kubernetesクラスタを持続可能にするために、いまからできること。 Sustainable Kubernetes = Baseline Kubernetes + Continuous Security + GitOps builderscon 2018の登壇資料です。 https://builderscon.io/tokyo/2018/session/d5a623d0-905f-4b25-8f70-cbf76afe9623
GitHub Codespacesは、仮想マシン上に強力な統合開発環境（IDE）を提供し、性能の低いマシンを持つ開発者がローカルリソースを消耗せずにコーディングできるようにし、AI画像の生成など様々なタスクに利用することが可能です。 GitHubが最近発表した「2022 State of the Octoverse」レポートにおいて、HashiCorp Configuration Language（HCL）がGitHubで最も成長したプログラミング言語となりました。HashiCorpは、クラウドコンピューティングのためのInfrastructure as Code (IaC) 自動化のリーディングプロバイダーです。HCLは、Terraformや Vaultなどのツールと共に使用されるHashiCorpの設定言語で、マルチクラウドやオンプレミス環境において、人間が読みやすい設定ファイルでIa
現仮想サーバー開発のソフトウェアアーキテクトが、SDPFクラウドの仮想サーバー開発の全体像や課題、目指す姿などを話す「元ウェブ系エンジニアが語る IaaS（VM屋さん）の開発ってなにしてんの？ 」。ここでNTTコミュニケーションズ株式会社の佐野氏と技術顧問の和田氏が登壇。最後に視聴者からの質問に回答します。前回はこちらから。 OpenStackはどれくらい改造しているのか？ 司会者：佐野さんありがとうございます。ここからは私のほうでSlidoを投映して、和田さんにモデレーションをお願いしたいと思います。では和田さん、お願いします。 和田卓人氏（以下、和田）：今もガンガン（質問を）書き込んでもらってかまいませんし、「この質問いいね」と思ったら「いいね」ボタンをどんどん押してください。みなさんが聞きたいと思った質問を基本的には優先しながら、時々、恣意的にピックアップしながら質疑応答をやっていき
RADIUSのクラウドネイティブ化で堪能したエンジニアリングの醍醐味 - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」
ISPの要であるRADIUSシステムのDevOps環境整備とクラウドネイティブ化を3年がかりで実現したことについて、技術検証で頓挫しかけた苦労話から、クラウド化のコツまで詳しくインタビューしました。 技術的負債を一気に返却するはずが存続の危機に 得意なことで補い合いながら課題をクリア フルリモートでも無事故のリプレースを実現したGitOps エンジニアが働く環境としてのBIGLOBEとは ISPの接続認証機能を担うRADIUSシステムを、コンテナやサーバーレス技術を活用して3年がかりでクラウドネイティブ化し、2022年6月から正式にサービスを開始しました。 それにあわせて、開発から運用までをスムーズに連携するDevOps環境を実現し、150台のオンプレミス・サーバーにかけていたシステム運用・保守工数を半減し、インフラ費用を従来の3分の2に圧縮することができました。 DevOps環境の特徴は
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitOps とデプロイ - Mitsuyuki.Shiiba
さくらインターネット株式会社を退職して博士後期課程に進学します - 水底
考察：Reactive Workflowが生まれた背景とその狙い - Kengo's blog
採用目的 2021 技術部編 - Pepabo Tech Portal
CI設定ファイル「.gitlab-ci.yml」の肥大化を防げ エンジニア1年生が“yaml地獄"から抜け出すためにやったこと
HERP における Web フロントエンド開発概観 (2022年春編)
A Guide to Secrets Management with GitOps and Kubernetes
転職会議のKubernetes移行のあゆみ - LIVESENSE ENGINEER BLOG
アソビュー！でのEKSクラスターの今までとこれから - asoview! Tech Blog
ガートナージャパンが「日本における未来志向型インフラ・テクノロジのハイプ・サイクル：2023年」発表
GitHub Actions でテストを並列化して CI 時間を短縮する - Gunosy Tech Blog
GitHub ActionsでGCPにTerraformでインフラCI/CDする - Qiita
Jenkins X - Cloud Native CI/CD Built On Kubernetes
食べログの大規模なレガシーシステムを段階的に改善していく取り組み - Qiita
A Kubernetes Development Workflow for MacOS 💻
Argo CDによってGKEでGitOpsをする - Kekeの日記
BUYMAの検索システムを刷新したお話 - エニグモ開発者ブログ
DX事業本部インフラの3年分の進化 (2019 ~ 2022) - Speee DEVELOPER BLOG
コマンドラインツールを用いずにCI/CDを行うGitOpsとは？
Sustainable Kubernetes
GitHub ActionsでIssueOpsによるブランチデプロイメントを可能にする
「OpenStackを選んだ理由は？」「VM屋になるためにどういった経験が大切か？」 元Web系エンジニアのVM屋に聞くQ＆A