並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 32 件 / 32件

新着順 人気順

argocdの検索結果1 - 32 件 / 32件

  • エンジニアは全員おうちKubernetesをやるべし【Part 1:なぜやるのか】 - Qiita

    こんにちは。おうちKubernetesを勧めるためにやってきました。 このシリーズでは、Part 1で「なぜやるのか」、Part 2で「どうやるのか」について話します。 この記事は自宅サーバー上のKubernetesで不特定多数向けのサービスを展開することを勧めるものではなく、自分用・身内用のアプリを自宅サーバー上のKubernetesで運用することを勧めるものです。 エンジニアは全員おうちKubernetesをやるべき絶対的な理由 自己研鑽のために (鑽←この字「研鑽」と「大鑽井盆地」でしか見ない) 企業がKubernetesを採用する場合、ほとんどがEKSやGKEといったクラウド上で動作するマネージドKubernetesサービスを使用すると思います。ただ、Kubernetesであればコマンドやマニフェストファイルの書き方は共通なので、おうちKubernetesで学んだことがそのまま業務

      エンジニアは全員おうちKubernetesをやるべし【Part 1:なぜやるのか】 - Qiita
    • Docker/Kubernetes 実践コンテナ開発入門 改訂新版を出版します

      こんにちは、ビコーペガサスです。この度、「Docker/Kubernetes 実践コンテナ開発入門 改訂新版」を出版します。本書は2018年に出版した初版を全面改訂したものです。 【新刊】2024年2月24日発売『Docker/Kubernetes実践コンテナ開発入門 改訂新版』本体3,600円+税,山田明憲 著,Docker/Kubernetesを実践で使いこなす!コンテナ開発・運用の第一歩!https://t.co/jRfsDFnuKu pic.twitter.com/dd0qo4DZM1 — 技術評論社販売促進部 (@gihyo_hansoku) February 13, 2024 「改訂新版」のモチベーション 初版の出版から早5年半が過ぎ、コンテナ技術の情報は大きく変化しました。コンテナ技術の基本的な部分は変わらないとはいえ、初版の内容が陳腐化するだけの時間が流れたことは否定しよう

      • ワークフロー実行基盤をFargateからEC2へ変更したらコストもパフォーマンスも改善できて幸せになった話 - ZOZO TECH BLOG

        はじめに こんにちは、ブランドソリューション開発本部バックエンド部SREブロックの小林(@mirai_kobaaaaaa)です。普段はWEARやFAANSというサービスのSREとして開発、運用に携わっています。 WEARではAmazon Elastic Kubernetes Service(以下、EKSと呼ぶ)を用いて複数システムのインフラ基盤を構築・運用しています。その中の1つとして、ワークフロー処理の実行基盤が存在しています。 本記事では、そのワークフロー実行基盤が抱えていた課題と、それらをどのように解決したのかを紹介します。また、付随して得られたメリットについても紹介いたします。 目次 はじめに 目次 WEARにおけるワークフロー ワークフロー処理内容 ワークフロー実行基盤の構成 ワークフロー実行基盤の課題 コスト内訳の調査 過剰なPodスペック Fargate実行時間の増大 ワーク

          ワークフロー実行基盤をFargateからEC2へ変更したらコストもパフォーマンスも改善できて幸せになった話 - ZOZO TECH BLOG
        • Platform Engineering on Kubernetes を読んでCloud Native の現在地を理解する - じゃあ、おうちで学べる

          はじめに 近年、Kubernetesの採用が進む中、複数のチームが関わり、複数のクラウドプロバイダーへのデプロイを行い、異なるスタックを扱う組織では、その導入の複雑さが新たな問題となっています。本書 『Platform Engineering on Kubernetes』は、Kubernetes に登場しつつあるベストプラクティスとオープンソースツールを活用し、これらのクラウドネイティブの問題を技術的に組織的にどのように解決するかを示してくれます。 learning.oreilly.com 本書では、Kubernetes上に優れたプラットフォームを構築するための要素を明確に定義し、組織の要件に合わせて必要なツールを体系的に紹介しており、実際の例とコードを交えながら各ステップをわかりやすく説明することで、最終的にはクラウドネイティブなソフトウェアを効率的に提供するための完全なプラットフォーム

            Platform Engineering on Kubernetes を読んでCloud Native の現在地を理解する - じゃあ、おうちで学べる
          • モノタロウがGoとprotobufで進める爆速マイクロサービス開発とそれを支えるプロセス - MonotaRO Tech Blog

            こんにちは。モノタロウのTechBlog編集チームです。 モノタロウではECサイトでのお客様体験の向上を目指して、日々改善に取り組んでいます。 商品の出荷目安などの出荷関連情報は重要な要素の1つになります。 今回は、出荷関連情報の正確性を改善するとともにシステムの変更容易性を向上させるためにマイクロサービス化に取り組んだ活動をインタビューしました。 自己紹介 納期表示を高度化する サプライヤ在庫連携機能開発のつらみ AVLのマイクロサービス開発のすすめ方 リリース・監視・その後の展開 おわりに 今回インタビューしたみなさん 自己紹介 山崎 章裕 ECシステムエンジニアリング部門 開発生産性グループ、プラットフォームエンジニアリング部門 CTO-Officeグループ AVLチーム兼務 2019年8月に入社し、主にECサイトの注文・配送周りのプロジェクトにテックリードとして関わる。またECサイ

              モノタロウがGoとprotobufで進める爆速マイクロサービス開発とそれを支えるプロセス - MonotaRO Tech Blog
            • はてなにおけるEKSの運用と自動化 (2024年版) - Hatena Developer Blog

              サービスプラットフォームチームで SRE を担当している id:masayosu です。 先月からですが Hatena Developer Blog にて SRE 連載を始めました。先月の記事は はてなブログの DB を RDS for MySQL 8.0 にアップグレードした話 - Hatena Developer Blog です。 毎月はてなの SRE が交代でブログ記事を書きますのでお楽しみに。 この記事は2024年2月の SRE 連載の記事です。 はてなの EKS 利用について 私が所属するサービスプラットフォームチームでは EKS の運用を続けており、先日 Kubernetes 1.23 から 1.28 へのアップグレードを完了しました。 私のチームは少人数で形成されているのですが、担当しているサービスは大小様々あり EKS クラスター上では数十個のサービスが稼働しています。 少

                はてなにおけるEKSの運用と自動化 (2024年版) - Hatena Developer Blog
              • なぜSUZURIはHerokuから「EKS」へ移設する決定をしたのか - Pepabo Tech Portal

                こんにちは。技術部プラットフォームグループのshibatchです。プラットフォームエンジニアとして、主にSUZURIとminneをより良くするおしごとをしています。 さて私が主として携わっているSUZURIですが、2014年のサービス開始以来、一貫してHerokuを利用してきました。このたび、10年間使っていたプラットフォームを卒業し、新たにAmazon EKS(Elastic Kubernetes Service)へ移す方針に決めた経緯についてお話しします。EKSに移すという決定にするまでに多角的に検討し、時に悩みながら決定した過程について明らかにしていきます。 なお、現在プラットフォーム移設の真っ最中であり、移設の詳細な内容はこの記事に含めません。移設作業はほぼ完了に向かっており、また別途お話しする予定です。 この記事は以下の3部構成になっています。 Herokuから移行しようと思った

                  なぜSUZURIはHerokuから「EKS」へ移設する決定をしたのか - Pepabo Tech Portal
                • エンジニアは全員おうちKubernetesをやるべし【Part 2:どうやるのか】 - Qiita

                  こんにちは。おうちKubernetesを勧めるためにやってきました。 このシリーズでは、Part 1で「なぜやるのか」、Part 2で「どうやるのか」について話します。 この記事は自宅サーバー上のKubernetesで不特定多数向けのサービスを展開することを勧めるものではなく、自分用・身内用のアプリを自宅サーバー上のKubernetesで運用することを勧めるものです。 ハード面 1台構成 or 複数台構成 複数台構成を取るメリットは大きいものだと以下があります。 1台が不調でも残りのサーバーで処理を継続できる(可用性が高まる) 大量のアクセスを捌ける 前者は、自宅サーバーでは気にしても仕方がないというか、停電やネット回線の障害で簡単に落ちるため、過度に可用性を気にする必要はないと思います。逆に言えば、可用性を気にする場合には、そもそも自宅サーバーはあまり向いていません。電源やネットを普段使

                    エンジニアは全員おうちKubernetesをやるべし【Part 2:どうやるのか】 - Qiita
                  • OpenTelemetry Collector導入の実践編とその後 - Gaudiy Tech Blog

                    はじめまして。Gaudiyでエンジニアをしているあんどう(@Andoobomber)です。 以前、「OpenTelemetry Collector導入のPoCと今後に向けて」という記事を弊エンジニアの sato(@yusukesatoo06)より公開しました。簡単に記事を要約すると、 OpenTelemetry及びOpenTelemetry Collectorの説明 実際にPoCを作ってみる 実導入を試みたがOpenTelemetry Collectorのホスティングに悩み、今後の課題として保留となった といった内容でした。 あれから1年経ち、GaudiyではOpenTelemetry Collectorを本番環境に組み込み、OpenTelemetryの仕様に準拠して計装し、データの分析や監視を行っています。この記事では、前回からの進捗を紹介すると共にOpenTelemetryの導入方法を

                      OpenTelemetry Collector導入の実践編とその後 - Gaudiy Tech Blog
                    • デザインシステムの開発者体験向上の試み - enechain Tech Blog

                      はじめに 今回書く開発者体験について 具体的な試み eslint pluginによるコーディング規約の明文化 Notionへのリソース集約 デザイントークンと型定義 おわりに はじめに こんにちは。enechainで働いている takurinton です。 enechainではさまざまな開発者体験向上の取り組みが試行されていますが、今回は自分が主に見ているデザインシステムにフォーカスして記事を書こうと思います。 弊社のデザインシステムに関しては、 @Shunya078 の なぜ我々はデザインシステムを創るのか? を読んでいただくと背景がご理解いただけると思います。 今回書く開発者体験について 開発者体験の定義についてはさまざまな解釈があると思いますが、今回は以下の3つのトピックに絞って紹介します。 eslint pluginによるコーディング規約の明文化 Notionへのリソース集約 デザ

                        デザインシステムの開発者体験向上の試み - enechain Tech Blog
                      • モノリシックなAPIでのカナリアリリース導入と開発者の認知負荷を減らすためConfigMapを使わない選択をした話 - MonotaRO Tech Blog

                        こんにちは、プラットフォームエンジニアリング部門コンテナ基盤グループの岡田です。 当社ではECサイトの裏側で利用されているモノリシックなAPIをコンテナ化し、Elastic Kubernetes Service (EKS) に移行しました。 移行直後は下記のようにトラブルに見舞われましたが、現状安定した運用ができています。 EKSコンテナ移行のトラブル事例:推測するな計測せよ -CoreDNS暴走編- - MonotaRO Tech Blog EKSコンテナ移行のトラブル事例:FargateにおけるAZ間通信遅延の解消 - MonotaRO Tech Blog 今回はトラブル事例ではなく活用事例になりますが、アプリケーションリリース起因でのトラブル影響を減らすため、コンテナ化したAPIに対してカナリアリリース導入を行いました。そのため、導入に際して生じたConfigやSecret周りの課題

                          モノリシックなAPIでのカナリアリリース導入と開発者の認知負荷を減らすためConfigMapを使わない選択をした話 - MonotaRO Tech Blog
                        • 23新卒エンジニアがチーム開発研修で学んだこと - Cybozu Inside Out | サイボウズエンジニアのブログ

                          こんにちは! 2023年新卒エンジニアの伴野・谷・和渕です。 サイボウズでは、2023年エンジニア新人研修の集大成として、チームに分かれてソフトウェア開発を行う実践演習が行われました。この記事では、各チームがどんな成果物を作成したのかを、チームごとにご紹介したいと思います。 エンジニア新人研修全体については以下の記事で詳しく紹介されています。ぜひそちらもご覧ください。 blog.cybozu.io 概要 実践演習では3チーム(「チーム gogo!」・「明日から」・「TEMBIN」)に分かれ、それぞれ一つのソフトウェアを2週間で開発しました。「サイボウズ流チーム開発を新メンバーだけで実践できた」「未知見の課題に対してどう行動すればよいか考えるきっかけになった」というコンセプトのもと、自由な発想で取り組みました。 チーム gogo! チーム gogo! では、演習開始時に Mastodon や

                            23新卒エンジニアがチーム開発研修で学んだこと - Cybozu Inside Out | サイボウズエンジニアのブログ
                          • SREエンジニアが目指すGKE共通デプロイ基盤の完成形 - ぐるなびをちょっと良くするエンジニアブログ

                            こんにちは。開発部門 開発部 Data AI Strategyセクション データ基盤 Unitの小野です。 2020年8月に入社してから早3年。SREエンジニアとして、日々業務改善に励んでいます。 ここ一年ほど、DAOという組織改善プロジェクトを推進していく中で、Google Kubernetes Engine (GKE)を使ったGKE共通デプロイ基盤の整備も進めてきました。 ※ DAOについての詳細はSREエンジニアが組織改善プロジェクトを立ち上げてみたを参照ください SREエンジニアの責務の一つは、プロダクトのリリースサイクルを極限まで短くし、次々と新しいサービスを世の中にリリースすることです。ChatGPTのような誰でも簡単に扱えるAIモデルが誕生したことで、プロダクト開発競争は今後ますます激しくなっていくと予想しており、SREエンジニアの責務の重要性をヒシヒシと感じています。 そう

                              SREエンジニアが目指すGKE共通デプロイ基盤の完成形 - ぐるなびをちょっと良くするエンジニアブログ
                            • あえて手動アップグレードを選ぶ〜マネージドサービス(GKE)で手作業による対応をした話〜 - MonotaRO Tech Blog

                              こんにちは。データ基盤グループ データエンジニアリングチームの宮口です。 この記事ではGoogle Cloud Platform(以下、GCP)のサービスの1つであるGoogle Kubernetes Engine(以下、GKE)のクラスタを手動アップグレードした話を紹介します。 私が所属するデータエンジニアリングチームでは、社内システムに保存されたデータをGCPのBigQueryにニアリアルタイムで同期するシステムや、BigQueryに保存されている大容量のデータを低レイテンシなAPIとして提供するシステムなど、モノタロウのビジネスを裏側で支えるシステムの管理を行っています。それらのシステムは全てのコンポーネントをコンテナ化しており、その実行環境としてGKEを採用しています。 また、それとは別に社内でGKE共通環境と呼んでいる、マルチテナント方式のクラスタによるアプリケーション実行基盤を

                                あえて手動アップグレードを選ぶ〜マネージドサービス(GKE)で手作業による対応をした話〜 - MonotaRO Tech Blog
                              • WEARにおけるKubernetesネイティブな負荷試験基盤の導入とその効果 - ZOZO TECH BLOG

                                はじめに こんにちは。ブランドソリューション開発本部バックエンド部SREの山岡(@ymktmk)です。普段はファッションコーディネートアプリ「WEAR」のSREとしてクラウドの運用やリプレイスをおこなっています。 昨年から、私たちのチームでは分散した技術スタックをKubernetesへ統一するリプレイスプロジェクトを開始し、先月ついにKubernetesへの移行が完了しました。 techblog.zozo.com また、Kubernetesへの段階的な移行と並行して、Kubernetesの柔軟性を活かした運用改善や開発者体験の向上に取り組んできました。その一環として、k6-operatorを活用した負荷試験基盤を作成しました。 本記事ではWEARにKubernetesネイティブな負荷試験基盤を導入した背景とその効果についてご紹介します。Kubernetes環境における負荷試験基盤の導入を検

                                  WEARにおけるKubernetesネイティブな負荷試験基盤の導入とその効果 - ZOZO TECH BLOG
                                • (Almost) Every infrastructure decision I endorse or regret after 4 years running infrastructure at a startup

                                  Image from UnSplash I’ve led infrastructure at a startup for the past 4 years that has had to scale quickly. From the beginning I made some core decisions that the company has had to stick to, for better or worse, these past four years. This post will list some of the major decisions made and if I endorse them for your startup, or if I regret them and advise you to pick something else. AWS Link to

                                  • freee 権限管理基盤を開発するチームの今を語ろう! - freee Developers Hub

                                    この記事はfreee 基盤チーム Advent Calendar 2023 の2日目の記事です。 こんにちは、freee の 権限管理基盤マイクロサービスを開発するチームでエンジニアリングマネージャーを務めている sentokun と申します。今回はその権限管理基盤チームの体制について語っていこうと思います。チームビルディング的な話としてお役に立てれば幸いです。 長い記事となったので、5日目との前後編でお送りさせていただきます。後編はこちらで公開予定。 チーム体制はざっくり以下の図のように立ち上げ期、探索期、構築期を経て現在に至っており、この記事では現在について記載していきます。後編では現在に至るまでの話を記載します。 チームの歴史イメージ 権限管理基盤とは?の記事: developers.freee.co.jp また、この記事では ユーザー = 基盤を利用する freee プロダクトとし

                                      freee 権限管理基盤を開発するチームの今を語ろう! - freee Developers Hub
                                    • ArgoCDバージョンアップを安全かつ迅速に行うための取り組み - freee Developers Hub

                                      概要 freeeではAmazon Web Services (AWS) Elastic Kuerbentes Service (EKS) 上にほとんどのアプリケーションが載っており、EKSへのデプロイ基盤としてはOSSの ArgoCD を利用しています。 ArgoCDから各クラスタにデプロイを行うため、非常に中央集権的なアーキテクチャとなっています。そのため、ArgoCDのバージョンアップは安全かつ迅速に行う必要があります。 本記事では、ArgoCDのバージョンアップの際に行っている取り組みをいくつか紹介します。 かなりマニアックですが、イントロダクションとまとめだけでも読んでいただければ幸いです。 イントロダクション 2023/04からfreeeでPlatform Deliveryチームに所属している gussan です。 Platform DeliveryチームはCI/CD全般のPla

                                        ArgoCDバージョンアップを安全かつ迅速に行うための取り組み - freee Developers Hub
                                      • Software Design 2024年6月号 連載「レガシーシステム攻略のプロセス」第2回 ZOZOTOWNリプレイスにおけるIaCやCI/CD関連の取り組み - ZOZO TECH BLOG

                                        はじめに 技術評論社様より発刊されているSoftware Designの2024年5月号より「レガシーシステム攻略のプロセス」と題した全8回の連載が始まりました。 本連載では、ZOZOTOWNリプレイスプロジェクトについて紹介します。2020年に再始動したZOZOTOWNリプレイスでは、「マイクロサービス化」が大きなカギとなりました。今回は、SRE部が行った、リプレイス方針の決定から導入ツールの選定、マイクロサービスのリリース方法の改善までを紹介していきます。 目次 はじめに 目次 ZOZOTOWNリプレイスにおけるSRE部の方針 IaCの導入 IaCとは プラットフォーム基盤におけるIaC CI/CDの導入 CI/CDとは GitHub Actions 変更のあるインフラリソースのみをCIの対象とする工夫 Canary Releaseの導入 Canary Releaseとは ZOZO A

                                          Software Design 2024年6月号 連載「レガシーシステム攻略のプロセス」第2回 ZOZOTOWNリプレイスにおけるIaCやCI/CD関連の取り組み - ZOZO TECH BLOG
                                        • 組織のクラウドオペレーションをいかにモダナイズするか | Amazon Web Services

                                          Amazon Web Services ブログ 組織のクラウドオペレーションをいかにモダナイズするか 過去 10 年間で、IT 運用チームとアプリケーション開発者が協調する方法は急速に進化してきました。かつて両チームには明確な責任分担があり、一方のチームはアプリケーション実行のためのサーバーやさまざまなコンポーネント(ストレージ、DNS、ネットワークなど)の提供と保守に重点を置き、もう一方のチームは主にアプリケーションの機能の開発、バグの修正、デプロイする成果物のパッケージングに重点を置いていました。最終的にこの分担はサイロ化されたアプローチにつながり、明らかな課題に直面します。サイロ化はチーム間のコミュニケーションを妨げます。開発者はコードをリリースする準備が整うと、運用チームにほとんど、あるいはまったく連携することなく引き渡すということがしばしばありました。その結果、運用チームは直前に

                                            組織のクラウドオペレーションをいかにモダナイズするか | Amazon Web Services
                                          • 【ArgoCD🐙️】KubernetesのマルチテナントパターンとArgoCDの実践テナント設計 - 好きな技術を布教したい 😗

                                            この記事から得られる知識 この記事を読むと、以下を "完全に理解" できます✌️ Kubernetesのマルチテナントパターンの種類 マルチテナントパターンをArgoCDで実践する場合にオススメのパターン (★) ArgoCDのNamespacedスコープモードとClusterスコープモード ArgoCDのテナントが防いでくれる誤った操作の具体例 記事のざっくりした内容は、以下のスライドからキャッチアップできちゃいます! この記事から得られる知識 01. はじめに 02. なぜマルチテナントが必要なのか シングルテナントの場合 マルチテナントの場合 03. Kubernetesのマルチテナントパターン マルチテナントパターンの一覧 Clusters as-a-Service Control Planes as-a-Service Namespaces as-a-Service カスタムリソ

                                              【ArgoCD🐙️】KubernetesのマルチテナントパターンとArgoCDの実践テナント設計 - 好きな技術を布教したい 😗
                                            • GitHub Actionsのcomposite actionを使ってinternalリポジトリのファイルを配布する - Cybozu Inside Out | サイボウズエンジニアのブログ

                                              クラウド基盤本部Cloud Platform部の pddg です。この前までチームだったんですが部になったらしいです。 引き続き精力的に cybozu.com のインフラ基盤の移行に取り組んでいます。 今回はKubernetesマニフェストのバリデーションのための仕組みを検討していたときに発見した、GitHub Actionsのちょっとハックっぽい、もしかしたら便利かもしれない手法について紹介したいと思います。 TL; DR 背景 テナントごとに分散しているマニフェスト kubeconformによるバリデーション テナントもNecoが使っているスキーマ定義ファイルを使いたい! internalリポジトリのclone トークンの作り方 GitHub Actionsのカスタムアクション GITHUB_ACTION_PATH には何が入っている? ファイルを配布するアクションを作る パラメータで

                                                GitHub Actionsのcomposite actionを使ってinternalリポジトリのファイルを配布する - Cybozu Inside Out | サイボウズエンジニアのブログ
                                              • 第7回: Argo CDによるKubernetesへの継続的デリバリ - CADDi ENGINEER Tech Blog

                                                ※本記事は、技術評論社「Software Design」(2023年10月号)に寄稿した連載記事「Google Cloudで実践するSREプラクティス」からの転載です。発行元からの許可を得て掲載しております。 はじめに 前回はRenovateによる依存関係の更新について解説しました。今回はArgo CD1を利用した、Kubernetesへの継続的デリバリ(Continuous Delivery、CD)について紹介します。Argo CDとは何か、なぜ使うのか、基本的な機能やキャディでどのように活用しているかを紹介します(図1)。 ▼図1 CADDiスタックにおける今回の位置付け Argo CDとは Argo CDはKubernetesへの継続的デリバリを行うツールです。Gitリポジトリをソースとして継続的デリバリを行う手法をGitOpsと呼びます2。Argo CDはKubernetesへのデ

                                                  第7回: Argo CDによるKubernetesへの継続的デリバリ - CADDi ENGINEER Tech Blog
                                                • KubeVirtを使って自宅VM基盤を構築する

                                                  VM基盤を管理するツールとして、KubeVirtがあります。KubeVirtを使うとKubernetes上でコンテナと同じようにVMを管理できます。自宅で簡単にVMを立てられるようにするためにKubeVirtを試してみたので、方法と感想をお伝えします。 KubeVirtとはVMをmanifestsとして記述すると、KubeVirtのControllerが良い感じにVMを作成してくれます。この時VMはコンテナと同じネットワーク上に存在するので、コンテナとの通信やアクセス制御などもKubernetesの仕組みに基づいて管理できます。 virtctl(kubectl virt)というCLIツールが提供されており、これを用いてVMをstart, stopしたり、ssh, console, vncなどでVMに接続したりできます。 またContainerized Data Importer(CDI)と

                                                    KubeVirtを使って自宅VM基盤を構築する
                                                  • VMからコンテナへ:Kubernetes移行時の懸念とArgoCDの活用 - Pepabo Tech Portal

                                                    13 期の@yumuと@donokunです。10 月のサイクル OJT はホスティング事業部にお世話になりました。今回は SRE チームに入り、ロリポップとヘテムルの Rails アプリケーションのコンテナ化を行いました。 背景 やったこと 既存アプリケーションの構成把握 ルーティングの移行後の構成と妥当性の判断 ArgoCD の活用 まとめ 背景 ロリポップとヘテムルは複数のロールで構成されるサービスです。その一部は VM で動作していましたが、徐々にコンテナ化を進めてきました。 コンテナ化する理由は色々ありますが、特に今回はメンテナンス面のメリットに着目しました。コンテナはアプリケーションとその依存関係を一つのイメージにカプセル化するため、VM よりも管理が簡単です。これにより、アップデートやパッチの適用が容易になり、メンテナンスにかかる時間とコストを大幅に削減できます。 VM の場合

                                                      VMからコンテナへ:Kubernetes移行時の懸念とArgoCDの活用 - Pepabo Tech Portal
                                                    • 今年サボった勉強を冬休みで全部取り戻す計画

                                                      どうも、仕事を納めてしまうと、何も予定がない人になってしまった人です... てなわけで、公式ドキュメント、リリースノート、信頼できる情報源全部読んじゃうぞという計画を立てました。計画倒れしないようにちゃんと読むことをブログで宣言します! 何をするのか マジでやること何もないので、日頃サボったプログラミングの勉強を一気にしようと思っている。「勉強していない」なんていうと「嘘つけ」と言われそうだが、いつも必要になったことをその都度調べて誤魔化しているだけであり、読むのは本や記事といった誰かの二次三次情報なので、実は一次情報には触れていない。なので以下に挙げるドキュメントは実はちゃんと読んだことがない。全て雰囲気で使っている。 そのため自分は歳の割には未知になっている範囲がとても多く(この構文ってフリーレンぽくてなんかかっこいいよね)、未知の未知にとても弱いため、わかっている人から見るとおかしな

                                                        今年サボった勉強を冬休みで全部取り戻す計画
                                                      • EKS Pod Identity を活用して Terraform でプロビジョニングした EKS を Blue/Green アップグレードしてみた | DevelopersIO

                                                        EKS Pod Identity を活用して Terraform でプロビジョニングした EKS を Blue/Green アップグレードしてみた EKS Pod Identity とは? EKS クラスター内の Pod に AWS 権限を与える新しい方式として EKS Pod Identity が発表されました。 Pod に Service Account 単位で細かく権限設定を行う際、 IRSA(IAM Roles for Service Accounts) を以前から利用できました。 こちらを使わずに EKS ノード単位で権限を付与すると Pod に必要以上の権限を付与してしまう可能性が高いため、IRSA はかなり一般的に利用されている機能かと思います。 Pod Identity も特定 Service Account 内の Pod から IAM ロールを利用可能にするための同じ目的

                                                          EKS Pod Identity を活用して Terraform でプロビジョニングした EKS を Blue/Green アップグレードしてみた | DevelopersIO
                                                        • IoT系のプロダクト開発の裏側って? 知られざる開発・運用ノウハウを2社のエンジニア6名が徹底解説! | gihyo.jp

                                                          IoT系のプロダクト開発の裏側って? 知られざる開発⁠⁠・運用ノウハウを2社のエンジニア6名が徹底解説! 電化製品や産業用機器など、あらゆるコンピューターやデバイスがインターネットを介して通信し、相互にやりとりする。そんな、IoT(Internet of Things)の技術を用いたサービス・ビジネスが注目を集めています。 2023年12月22日に開催されたイベント「IoT系のプロダクト開発の裏側って?知られざる開発・運用ノウハウを2社のエンジニア6名が徹底解説!」では、IoT技術を事業に活用するENECHANGE株式会社と株式会社スマートショッピングのエンジニア合計6名が登壇。プロジェクトから得られた知見を紹介しました。今回はそのレポートをお届けします。 今回登壇した発表者の集合写真 高度なモノの管理を実現⁠:SmartMatのエンジニアリング紹介 はじめに登壇したのは、スマートショッピ

                                                            IoT系のプロダクト開発の裏側って? 知られざる開発・運用ノウハウを2社のエンジニア6名が徹底解説! | gihyo.jp
                                                          • コンテナオーケストレーションとGoogle Kubernetes Engine(GKE)の特徴とその活用 | gihyo.jp

                                                            本連載は、Google Cloudのアプリ開発とDBプロダクトにおけるスペシャリスト達が、Google Cloudプロダクトを利用した、クラウドネイティブな開発を実践する方法を解説しています。 第2回では、Google Cloudが提供するフルマネージドなKubernetesプラットフォームであるGoogle Kubernetes Engineのアーキテクチャや特徴を紹介します。この記事を読むことでGoogle Kubernetes Engineのユースケースや利点について理解できます。 対象となる読者として、クラウドを利用したアプリケーションプラットフォームを開発/運用するエンジニア、またそのプラットフォーム上でアプリケーションを開発するエンジニアを想定しています。 Kubernetesとは KubernetesはOSSのコンテナオーケストレーションシステムです。 Google内部で利用

                                                              コンテナオーケストレーションとGoogle Kubernetes Engine(GKE)の特徴とその活用 | gihyo.jp
                                                            • CADDi DRAWERにE2Eテスト自動化の導入を進めています - CADDi Tech Blog

                                                              こんにちは、DRAWER Enabling QAチームの猿渡です。 この記事ではDRAWER QAチームで進めているE2Eテスト自動化についてご紹介します。 課題 CADDi DRAWERにはQAチームがあります。品質保証業務は、開発エンジニアや外部パートナーなど様々な方と連携し行っています。 現在QAが行っているテストは、システム全体をスコープにしたエンドツーエンド(E2E)テストです。。 CADDi DRAWERでは、DRAWER Product Testing Guidelineにより、以下のテストカテゴリを定義しており、E2Eテストでは、Test Size: Largeの「Story Tests」と「Scenario Tests」のCategoryに対してソフトウェアテストライフサイクル(STLC)を行っています。 [DRAWER Product Testing Guideline

                                                                CADDi DRAWERにE2Eテスト自動化の導入を進めています - CADDi Tech Blog
                                                              • GitHubのorganization移行をやったお話 - 生涯未熟

                                                                この記事はSRE Advent Calendar 2023の1日目の記事です。 今回は業務で「GitHubリポジトリをあるorganization(以下、org)から別のorgへ移行させる」ということをやったので、その時のお話をさせていただきます。 何をするのか? もう少し、何を目標としていたのか?を具体的に書くと、現在リポジトリ群が所属しているorgからGitHub Enterprise Cloud(以下、GHEC)配下に作成したorgへ移行させる、ということをやろうとしたお話になります。 GHECに移行するモチベーションとしてはGitHub Copilot for Businessが利用できたり、SAML SSOを利用できたりするというメリットを受けることが出来るからですね。(開発者にとってはCopilotが理由として大きいかも) 移行前の状況 移行前は以下のような状況でした。 自分が

                                                                  GitHubのorganization移行をやったお話 - 生涯未熟
                                                                • kubernetesをココナラで本番運用出来るか試行錯誤している話

                                                                  こんにちは! 株式会社ココナラのインフラ・SREチーム所属のおさだと申します。 本記事では、コンテナオーケストレーションのデファクトスタンダードであるkubernetesに対する弊社の取り組みについて紹介いたします。 ココナラのサービス開発の課題 こちらの記事でも述べている通り、弊社サービス開発には以下の課題があります。 現状アプリケーション基盤がEC2、ECS+EC2、ECS+Fargateに分散しており、運用管理コストや拡張性に課題がある 新規機能毎にインフラを構築する工数を確保出来ずに、既存アプリケーションの肥大化が進んでいる 既存アプリケーションに実装することにより、新規機能に適した言語を選択する幅が狭まっている kubernetesが上記課題の解決手段になりうるか、導入検討を進めております。 kubernetes導入検討でやったこと 直近では以下の対応を実施しており、それぞれ内容

                                                                    kubernetesをココナラで本番運用出来るか試行錯誤している話
                                                                  1