OpenCI ランナーを使えば、GitHub Actionsのコストを大幅に下げ、CI/CDの処理速度を向上させることができます。
OpenCI ランナー 🇯🇵 - 国産のオープンソースなサードパーティ GitHubランナー
OpenCI ランナーを使えば、GitHub Actionsのコストを大幅に下げ、CI/CDの処理速度を向上させることができます。
Self-Hosted Runnerで GitHub Actions のCI/CDを高速化・コスト最適化した
はじめに Dress Code Advent Calendar 2025 の10日目の記事です。 GitHub Actionsは非常に便利なCI/CDツールですが、プロジェクトが成長するにつれて、GitHub-hosted runnersだけでは対応しきれない課題に直面することがあります。 本記事では、AWS上にSelf-Hosted Runnerを構築し、CI/CDパイプラインの高速化とコスト最適化を実現した取り組みについて紹介します。同様の課題を抱えている方の参考になれば幸いです。 背景・課題 私たちのプロジェクトでは、GitHub-hosted runnersを使用する中でいくつかの課題が顕在化していました。 リソース不足 プロジェクトの規模が大きくなるにつれ、ビルドやテストに必要なCPUとメモリが増加しました。特にNode.jsアプリケーションの大規模なビルドでは、GitHub-h
GitHub Self-hostedに移行しました。CIが最大55%速くなり、月額が300万円節約できた！
こんにちは、SODAのSREチームのDucと申します。 GitHub Actionsのコストを削減しながらCIワークフローを高速化したの工夫をご紹介します。 背景 私たちのチームは、snkrdunk.comサイトとSNKRDUNKモバイルアプリの可用性とパフォーマンスの維持に注力しています。 それに加えて、クラウドインフラストラクチャやその他の監視・開発ツールのコスト管理も担当しています。 毎月、AWSやGitHubなどのインフラストラクチャとツールの請求書をチェックしています。 GitHubの請求額が非常に高いことに気づきました。特にGitHub Actionsの部分です。 参考までに、GitHub Actionの使用量とサーバーの本番ワークロード費用の比較をご紹介します。 Fargate: Savings Plan適用で月額約$7,000。私たちのサービスは平均約5000リクエスト/秒
日本ではKubernetesやCI/CDなどが幻滅期に、インダストリクラウドやインフラ自動化は過度な期待。「日本におけるクラウド・プラットフォームのハイプ・サイクル」2024年版発表
日本ではKubernetesやCI/CDなどが幻滅期に、インダストリクラウドやインフラ自動化は過度な期待。「日本におけるクラウド・プラットフォームのハイプ・サイクル」2024年版発表 調査会社のガートナージャパンは、「日本におけるクラウド・プラットフォームのハイプ・サイクル：2024年」を発表しました。 ハイプサイクルとは ガートナーのハイプサイクルは、技術の登場から安定までを5つのステージに分けて説明したものです。5つのステージは、「黎明期」から始まり、「『過度な期待』のピーク期」「幻滅期」「啓発期」「生産性の安定期」まで。この途中で消えていく技術もあります。 同社はグローバルだけでなく国別などさまざまな切り口でハイプサイクルを発表しています。今回発表されたのは日本のクラウドプラットフォームにおけるハイプサイクルです。横幅の関係上、図を2つに分割しました。まずは前半部分。 黎明期にはFi
CI/CDのデータを収集するCIAnalyzerの紹介
去年のGWにCIAnalyzerというツールを作成し、プライベートと仕事の両方で1年ほど活用してきました。今年の9月にCI/CD Conference 2021にて実際の活用事例を紹介させて頂きましたが、発表時間の都合上CIAnalyzer自体の使い方まで紹介はできなかったためブログにしました。 CIAnalyzerを作成したきっかけ 今の自分の仕事は社内のCI/CDの基盤を整えるのと同時に、ビルドエンジニアの真似事のようなことをしています。この分野のサポートをしていると開発を主にしているエンジニアの方から 「ビルドが遅いし、頻繁に壊れる」 「テストは時間がかかるし、いつも失敗している」 という話を聞く機会がありました。ですが、自分としてはとても意外なことにその実態を定量的に把握することはほとんどできませんでした。 もちろん短期的であれば把握できます。昨日のデプロイはN分かかったとか、ma
Docker Buildにおけるリードタイム短縮のための3つの改善ポイント | PLAID engineer blog
こんにちは、エンジニアの oga です。2019/12に入社してプロダクト開発業務に携わっています。 プレイドでは、KARTE の開発及び実行環境としてDockerやk8sを活用していていますが、私自身はこれまでPaaSやFaaSなどのコンテナ管理が隠蔽されている様な形やそもそもコンテナを使わない開発が多かったので、Dockerfileに構築のコマンドを書き連ねてdocker build でバシッとイメージができる便利！ぐらいの理解度でした。 今回はそんな中から基礎として学んだDockerfileのベストプラクティスを、 リードタイム（CI/CDの実行時間）を短縮し開発生産性を向上させる為に行うべき事 という観点でまとめました。 大筋は 公式のベストプラクティス に挙がっている手法を理解し易く整理し、重要だけど分かり辛い部分を解説する内容になります。 3つの改善ポイントDocker Ima
入門 GitHub Actions - メドピア開発者ブログ
CTO室SREの @sinsoku です。 社内のGitHub ActionsのYAMLが複雑になってきたので、私が参考にしてる情報や注意点、イディオムなどをまとめておきます。 頻繁に参照するページ 新しい機能の説明が日本語ページに反映されていないため、基本的に英語ページを読むことを推奨。 ワークフロー構文 YAMLの基本構文の確認 コンテキストおよび式の構文 github オブジェクトの情報、関数の確認 ワークフローをトリガーするイベント 各イベントの GITHUB_SHA と GITHUB_REF が記載されている About GitHub-hosted runners インストールされているSoftwareのバージョンなどが記載されている GitHub REST API APIを使うときに参照する よく使うaction actions/checkout イベントによってはデフォルトブ
CircleCIが「Visual Config Editor」を正式リリース、CI/CDパイプラインをビジュアルに作成しYAMLファイルを生成、編集可能
CircleCIが「Visual Config Editor」を正式リリース、CI/CDパイプラインをビジュアルに作成しYAMLファイルを生成、編集可能 CircleCIは、ビルドやテストを自動的に実行するCI/CDのパイプライン定義をフローチャートを描くようにビジュアルに設定できる「Visual Config Editor」の正式リリースを発表しました。 We're rolling out a new, frictionless way to build #CICD pipelines and interact with our platform. Introducing the CircleCI Visual Config Editor See how you can easily create and modify config files in a visual drag-and-
NGINX、商用版の重要な機能をオープンソースで無料化、オートスケールやCI/CDフックなどフルスタック化など、今後の発展についてコミットを発表
NGINX、商用版の重要な機能をオープンソースで無料化、オートスケールやCI/CDフックなどフルスタック化など、今後の発展についてコミットを発表 オープンソースのWebサーバ「NGINX」（エンジンエックス）の開発元であるF5 Networksは、オンラインイベント「F5 NGINX Sprint 2022」を開催中です。 そこでNGINX開発チームは、今後のNGIXの発展に向けて、ソースコードをMercurialからGitHubへ移行すること、有償版の機能をオープンソースへ移植して無料で利用可能にすること、単なるWebサーバ機能だけでなくCI/CD機能などを拡張することなど、3つの約束を発表しました。 GM of #NGINX @rwhiteley0 has just announced three #opensource promises that will come to life
毎日何度も本番環境にデプロイをしている話 - Mitsuyuki.Shiiba
CircleCI に入って色々と面白いなぁって思いながら毎日楽しんでる。その楽しんでることのひとつに Git のブランチモデルがある。最初はびっくりしたけど、慣れるととても良い 最初に言っておくと、この手法がどこにでも当てはまるとは思ってない。業種や、開発形態、プロダクトのタイプなどによって合うやり方は違う。単に CircleCI には、この手法がとても合ってるなぁと思う トランクベースのブランチモデル タスクに着手するときは、まずメインブランチからそのタスク用のブランチを作る。develop ブランチや release ブランチみたいな長く生きてるブランチはない。そのタスク用のブランチにコミットをプッシュしたらプルリクエストを出す。そして、レビューが終わればメインブランチにマージされる。タスクに着手してからマージまで、はやければ1時間ぐらい。長くてもだいたい2,3日くらい そして、メイン
Docker創始者らが開発、ビルド／テスト／デプロイの自動化をポータブルにするツール「Dagger」登場。そのままローカルでもGitHubでもCircleCIでも実行可能に
Docker創始者らが開発、ビルド／テスト／デプロイの自動化をポータブルにするツール「Dagger」登場。そのままローカルでもGitHubでもCircleCIでも実行可能に Dockerの創始者であるSolomon Hykes氏らが中心となって開発しているオープンソースのCI/CD環境構築ツール「Dagger」が公開されました。 Windows、Mac、Linuxで試すことができます。 And we are live! Introducing Dagger, a new way to build CI/CD pipelines. By the creators of Docker. https://t.co/DU8racmoUo — dagger (@dagger_io) March 30, 2022 Daggerが定義したCI/CDパイプラインはポータブルになる Daggerとは「A P
CIOpsとGitOpsの話 - inductor's blog
はじめに GitOpsという言葉が生まれたのが自分の知る限り2017年頃なのですが、世の中にあるCI/CDの仕組みはまだほとんどがCIOpsもしくは手動のオペレーションによって成り立っていると思っていて、かつては自分もそうだったのですが「Gitで管理されていればGitOpsなんでしょ？」という勘違いを払拭したくてこのエントリーを書いています。 GitOpsとCIOpsは全然違う まず前提としてGitOpsの明確な定義を知らないという場合、あなたの思う「Gitを契機とした自動デプロイの仕組み」は基本的にはCIOpsです。GitOpsとCIOpsは思ったよりも大きな違いがあって、そもそもGitOpsの必要性が分かっていない場合、自動化によって成立しているデプロイはCIOpsが基本です。 CIOpsとGitOpsの一番の違いは、Push型かPull型かである CIOpsの場合、例えばGitHub
メルカリShops の CI/CD と Pull Request 環境 | メルカリエンジニアリング
こんにちは！ソウゾウの Software Engineer の @dragon3 です。 連載：「メルカリShops」プレオープンまでの開発の裏側の８日目を担当させていただきます。 この記事では、メルカリShops 開発において、日々バリバリに利用されている CI/CD 環境と Pull Request 毎のデプロイ環境について紹介します。 CI/CD 環境 メルカリShops では、CI/CD （テスト・ビルド・デプロイ）やその他自動化のために GitHub Actions を使っており、ほとんどのワークフロー・ジョブを Self-hosted runners で実行しています。 Self-hosted runners は、専用の VPC ネットワーク 内の GCE インスタンス上で動かしており、Managed Instance Group 等を使い、そのプロビジョニングや起動・停止等は
GitHub Actionsに「強い」AWSの権限を渡したい ~作戦3 - AssumeRole with Google ID Token ~ - KAYAC engineers' blog
こんにちは。技術部の池田です。 この記事では、Github Actions上に「強い」AWSの権限を渡すために以下のことを行います。 App Runnerでお手軽にGoogle ID Token 取得するためのWeb Applicationを動かす。 Web Applicationから取得できるGoogle ID Tokenを信頼するIAM RoleにAssumeRoleする。 AssumeRoleによって得られた一時的な強い権限で、強い権限を要求する作業(Deploy, Terraform Apply)をGithub Actionsで行う。 これにより、Github Actions上にAWSのアクセスキーを置かずに、ある程度安全な方法でAWS上での強い権限を要求する操作を実行できます。 そのため、例えばGithub Repositoryに不正アクセスされてしまったとしても、AWSの本番環
CIと食洗機 - Konifar's ZATSU
ソフトウェア開発の経験がない嫁氏と、たまに開発の話をする。いつだったか、たしか個人開発している時だったと思うが、CIとCDを先に整えておくのはとても重要という話をした。 仕事が終わってからもMacbookをいじっている自分に「今何してるの？」と聞かれたのがきっかけだった気がする。「開発に入る前の下準備だよ」「下準備って？」「やっておいた方がそのあとの効率がよくなることってのがいくつかあって、それをやってる」「たとえば？」「CI/CDの設定とか」みたいな感じ。そこからCIの説明に入った。ざっくりまとめると以下のような会話だ。 CIというのは、食洗機のようなものだ。我々も食洗機を使い出す前は「食洗機なくてもいいよね」という話をしていたと思う。しかし今はどうだ？食洗機がない生活は考えられない。食洗機をもっと早く買っておくべきだったという共通認識がある。 使い出す前はどうだったか。「何でも洗えるわ
1,000円以下のUSB 3.1対応Type-C to Type-Cケーブルには要注意
Amazonでは1,000円以下のUSB 3.1対応Type-C to Type-Cケーブルが売られていますが、ロクなものではない可能性が高いので注意しましょう。 USB 3.1対応のType-C to Type-Cケーブルは高価 USB Type-C to Type-Cケーブルは「USB 2.0対応品」と「USB 3.1対応品」の2つに大きく分けられます。 この2種の価格を比べてみると基本的にUSB 3.1対応品のほうが高価であり、メーカーによっては2倍以上の価格差がついていることも珍しくありません。 例として、AmazonベーシックのUSB Type-C to Type-Cケーブルを比較してみます。 2017年11月4日時点では、USB 2.0対応品が333円、USB 3.1対応品が1,475円となっています。2倍どころか4倍以上の価格差ですね。 このように明らかな価格差があるUSB
1ヶ月間仕事でOSSの開発をしてきた - TeCH8Ki
こんにちは、TaKO8Kiです。 3/2から3/31までサイバーエージェントのDeveloper Productivity室でPipeCDというOSSのCDツールの開発を行うインターンをしていました。 以下では、仕事でOSSの開発をしたことの感想と実際に取り組んだタスクについて書いていきます。 PipeCDとは？ Docsから引用すると下記のようなものです。 PipeCD provides a unified continuous delivery solution for multiple application kinds on multi-cloud that empowers engineers to deploy faster with more confidence, a GitOps tool that enables doing deployment operations
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Codemagic - CI/CD for Flutter
開発環境のセキュリティおよびCI/CDパイプラインのセキュア化
GitHub Actionsのローカル実行ツール「act」を使う事でCI/CDコンフィグとローカルでのタスクランナーを1つにする | DevelopersIO
