GitHub ActionsでDocker Buildするときのキャッシュテクニック - cockscomblog?
GitHub Actionsでdocker buildすることが多い。このときのキャッシュをどうするかという話題。 基本 GitHub Actionsでdocker buildしてAmazon ECRにdocker pushする、典型的な.github/workflow/docker-push-to-ecr.ymlはこういう感じ。 name: Push to Amazon ECR on: push: branches: [ 'main' ] jobs: docker: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: docker/setup-buildx-action@v1 - name: Configure AWS credentials uses: aws-actions/configure-aws-c
CircleCIが無料枠を大幅拡大。1カ月あたり6000分のビルド時間、ユーザー数無制限、最大30件までのジョブ同時実行など
CircleCIが無料枠を大幅拡大。1カ月あたり6000分のビルド時間、ユーザー数無制限、最大30件までのジョブ同時実行など CI/CD機能をクラウドサービスとして提供するCircleCIが、無料枠を大幅に拡大したことを発表しました。 At CircleCI our mission is to help teams deliver software faster and better. We’re so confident that you’ll be successful with CircleCI that we’ve added more features and more resource classes than ever before to our Free plan. https://t.co/oEuEREcTkv — CircleCI (@CircleCI) January
上位組織のデプロイ頻度は1週間に約30回 1日1デプロイだったメドピアが挑んだ頻度改善の取り組み
多数のヘルステックサービスを企画・開発しているメドピアが、リモートワーク継続中でも事業成長を加速させたプロダクト開発の事例や技術的な知見を紹介する「事業成長を加速させたエンジニアリングのウラ側」。ここで「Deploy Rails apps in 2021」テーマに正徳氏が登壇。まずは過去のレポートをもとにした目指すべきデプロイの頻度と、デプロイ改善のために取り組んだことについて紹介します。 自己紹介 正徳巧氏（以下、正徳）：「Deploy Rails apps in 2021」というタイトルで発表します。ちょっと私も緊張しているので、ビールを飲みながら発表させてください。 自己紹介です。正徳と言います。会社に入社して1年半ぐらいで、CTO室のSREという部署に所属しています。SNSなどは@shinsokuというハンドルネームで活動しています。よろしくお願いします。 SREでなにをやっている
CI/CD Conference 2021 by CloudNative Days
CI/CD Conference 2021 by CloudNative Days Continuous 〜 技術を知り、試し、取り入れる 〜
CI設定ファイル「.gitlab-ci.yml」の肥大化を防げ エンジニア1年生が“yaml地獄"から抜け出すためにやったこと
技術とノウハウを武器に、膨大かつ複雑なデータの「検索」「分析」「可視化」といった課題を解決するフォルシア株式会社が「FORCIA Meetup #2」を開催しました。2回目の今回のテーマは「2020年度にエンジニアが取り組んだこと」。六車氏は、CI/CDの整備について発表しました。 管理ツールとして「GitLab」CI/CDツールとして「GitLab CI/CDツール」を利用 六車光貴氏（以下、六車）：六車が『エンジニア1年目の貢献：CI整備を中心に』というタイトルで発表します。まず自己紹介です。六車光貴と申します。ちょっと変わった名前ですが、四国の香川県出身で、香川県だと小学校のクラスに1人はいる名前です。 フォルシアには2020年4月に新卒で入社して、ソフトウェアエンジニアとして働いています。主に大手旅行代理店のサイトの構築をTypeScript、Node.js、React、Next、
GitHub Container registry が GA したので触ってみる
GitHub Container registry とは GitHub Packages を構成する1つで Docker を始めとしたコンテナを扱えるレジストリです。 Docker registry (docker.pkg.github.com) から Container registry (ghcr.io) へ統合されました。 パブリックコンテナへの匿名アクセス コンテナの Organizational レベルの所有権 コンテナのきめ細かいパーミッション制御 有益な情報が豊富なコンテナ用ランディングページ コンテナの可視性はリポジトリの可視性から独立 Organizational におけるコンテナの内部的な可視性設定 GITHUB_TOKEN による Actions ワークフローからコンテナへのセキュアでシームレスなアクセス Container registry (ghcr.io) へパ
GitHub Actions のデバッグをローカルで行う
概要 GitHub Actions で GitHub ホストランナーを使用する場合、パブリックポジトリは無料ですがプライベートリポジトリは従量課金（無料枠あり）です。 ワークフローを編集する際にデバッグしていると結構な時間を消費してしまいます。 そこでデバッグ時は GitHub ホストランナーを使わずに無料で実行する方法を 3 種類紹介します。 nektos/act 言わずと知れたローカル実行ツールです。 すべてを再現することはできませんがコミットを増やさずにデバッグができます。 注意点 ubuntu-* のみサポート ソフトウェアは指定する Docker イメージ依存、デフォルトのイメージだと色々足りないので -P で指定 secrets.GITHUB_TOKEN が未定義なので Personal Access Token を発行し設定が必要 サービスコンテナ services が使えな
AWS CI/CD for Amazon ECS ハンズオンをやってみた | DevelopersIO
概要 AWS CI/CD for Amazon ECS ハンズオンをやってみました。 ハンズオンは下記の3本立てです。3時間程度で終わりました。 サンプルアプリのコンテナイメージ作成 AWS Fargate環境構築とコンテナ実行 CI/CDのパイプライン作成 ハンズオンを進めながら個人的なメモを補足した内容です。実際のハンズオン資料を見ながら作業をすすめ補足資料になればよいなと思っています。 CodeBuild時にDocker Hubのレートリミットに引っかかるとつまづくと思うのでそこの回避方法を載せています。 まず、AWS Fargateとは ハンズオン1 Fargateでコンテナを実行するまでの前準備する内容です。 ハンズオン資料より VPC、ALB作成 ハンズオンの手順ではVPCはCloudFormationで構築します。コードはハンズオン資料内にダウンロードリンクがあります。ALB
Github Actionsをcronとして利用し、notify-issues-to-slackを動かす - $shibayu36->blog;
以前、レビュータイムや定期的なissueチェックのためにGithubのissueを検索してSlackに投稿するCLIツールを作ったで紹介したnotify-issues-to-slackだが、これまでは 適当に立てたサーバーのcronで動かす Jenkinsなどで実行する という方法で動かしていた。 しかし、issueをslackに通知するためだけにサーバーを立てたりするのもだるい。そこでGithub Actionsで動かしてみた。 Github Actionsを動かすレポジトリのみを対象とする場合 secrets.GITHUB_TOKENを使えば、そのレポジトリへアクセス可能なので、何も設定せずとも以下のように設定できる。 .github/workflows/notify-issues.yml name: daily bug report on: schedule: - cron: 30
SECCON Beginners CTF 2020の監視・オペレーションを支える技術 - ポン酢ブログ(β)
LifeMemoryTeamの@atponsです。今回のSECCON Beginners CTF 2020はお楽しみいただけたでしょうか。自分は運営やインフラ整備をしておりました。 今回は、自分が担当していた監視、オペレーション部分の構築回りについて書いておきます。 死活監視 バッジ 今回参加者のみなさんには、このようなバッジを問題に付与して提供しておりました。これによって、問い合わせのオペレーションを削減することを目標に、昨年も取り組んでおりました。バッジでは、そのタスク（問題からフラグを取れたかどうか、サービスに疎通できるかどうか）の成功可否を表示していました。 また、最後にタスクを実行した時間を表示できるようにしていました。このバッジ生成は完全に自作したものです。詳細は死活監視の部分で書きます。 タスクランナー 定期的に実行してその状態を知りたい、という要望にはCI/CDツールを応用
GitHub Actions + CircleCI でDocker HubへDockerイメージを登録、定期的にre-buildする - Qiita
GitHub Actions + CircleCI でDocker HubへDockerイメージを登録、定期的にre-buildするCICircleCIDockerDockerHubGitHubActions GitHub Actions + CircleCIを利用してDocker HubへDockerイメージを登録、定期的にrebuildする方法を解説します。 実際に動いているサンプルコードはこちらで確認出来ます。 DockerイメージのビルドのCIを行う CI用途のためリポジトリにpushがあったら全てのブランチでCIが実行されるように設定します。 利用するAction Build and push Docker images · Actions · GitHub Marketplace DockerfileからDockerイメージのビルドとDocker HubへDockerイメージの
ZAP – ZAP Docker Documentation
ZAP’s docker images provide an easy way to automate ZAP, especially in a CI/CD environment.
プルリクに対して検証環境を自動で起動/終了するプログラムを作ったら、検証が捗った話 - Qiita
記事の概要 GitHub Flowでの開発、つまり単純なプルリク運用での開発を、営業も巻き込んで実践したいと思い、そのような環境を作りました。その際、いくつか足りない機能を補うウェブアプリを作って公開したので、それに関する様々な話を書きます。 （実際にこのウェブアプリを使えるかどうかというよりは、似たようなフローで開発を改善できるといいなというような目的の話です。） ウェブアプリのリポジトリ このウェブアプリの使い方と機能については、一応README.mdに書いていますが、この記事では少し背景的な話も含めて順番に書きます。 issue対応やその他追加開発などは絶賛募集中です。 背景 開発に関するよくある課題 これまで、既存のウェブアプリ（サービス）の機能追加開発において、以下のような課題がありました。 検証が十分にできていない機能がある 追加した機能の使い方を十分にレクチャーできていない/
First Docker GitHub Action is here! | Docker
We are happy to announce that today Docker has released its first Github Action! We’ve been working with GitHub, looking into how developers have been using GitHub Actions with Docker to set up their CI/CD workflows. The standard flows you’ll see if you look around are what you’d expect: building an image, tagging it, logging into Hub, and pushing the image. This is the workflow we’ve aimed to sup
リモートで動くDockerにファイルを送ったり持ってきたりする方法 | DevelopersIO
こんにちは、本日からCX事業部(Customer eXperience)所属になった夏目です。 サーバーレスのCI/CDでDockerを使っているのですが、そこで少し問題になったことを書いていきます。 問題 CircleCIやCodeBuildではDockerコマンドが使えます。 なので既存のDockerイメージを使用してテストやビルドをすることも珍しくもないと思います。 しかし、Dockerそのものはコマンドを実行しているローカルではなく、リモート上にあることが多いです。 そのため、-vオプションを使ってファイルを共有したりすることができません。 解決方法 ローカルのファイルをリモートのコンテナで使う方法 ローカルのファイルを追加するDockerImageを作成し、それをリモート上のDockerで動かすことで、ローカルのファイルをリモート上のDockerコンテナで使用することができます。
CIとTest Sizesの話 - asterisc
はじめに 前回 akito0107.hatenablog.com どちらかというとこっちが本編。 前回の記事ではTest Sizesについて紹介したが、今回の記事はその分類が実際の開発にどう役に立っているのかをまとめたいと思う。もちろん用語の統一も大きな意味を持つが、それ以外のことを書いていきたい。 具体的には、CIでテストのパイプラインを組む時にこの分類どおりに組んでいくと綺麗に整理でき、CI全体のスループット向上にも効果がでているという話だ。今回の話は僕たちのチームに特化した内容になるが、1) Test SizesごとにTestの起動コマンドを分ける、 2) Smallから順に実行していき、落ちるべきテストはできるだけ早期に落とす、というポイントはどこにでも使えるものだと思う。 コンテナ技術とテスト 僕たちはローカルの開発環境だけではなく、本番環境やCI環境でコンテナ技術（主にDock
Kubernetesで安全にアプリケーションをデプロイするCDツール“Spinnaker”とは
4月19日に開催された「Japan Container Days v18.04」カンファレンス。「Spinnakerを利用したKubernetesへの継続的デリバリ」のセッションでは、株式会社エーピーコミュニケーションズの溝内 崇氏が、CDツールの「Spinnaker」を解説した。 Spinnakerはクラウド用CDツール 溝内氏は冒頭で本セッションの内容について「Kubernetesの環境で安全にアプリケーションをデプロイする仕組み」と紹介。Kubernetesでは実現が難しい課題として「CI/CDの機能がなく別途用意する必要があること」を挙げた。 CI/CDには、テストなどを回し開発者に問題をフィードバックして高品質を保つ「CI（継続的インテグレーション）」と、CIで作られた高品質なものをステージングやプロダクションにもっていく「CD（継続的デリバリ）」が含まれる。これらは、高品質なプ
Elastic Beanstalk の Platform を Ruby から Docker へ移行した話 - SmartHR Tech Blog
こんにちは！ SmartHRエンジニアの @tei-k です。 SmartHR ではインフラに AWS の Elastic Beanstalk (以降 EB ) を使っています。 Rails アプリですので、去年までは Ruby Platform 上で動いたのですが、今年から Docker Platform へ切り替えました。 ここでは移行するまでの工夫をご紹介できればと思います。 EB の概要 EB は、インフラストラクチャーを意識せず簡単にアプリケーションの構築、デプロイ、Auto Scaling などをマネジードしてくれる PaaS となります。 Ruby、Go など様々な言語や Docker にも対応しているため、すべての言語のアプリを EB 上で動かせるでしょう！ 詳細は公式ドキュメントご参考下さい。 移行の背景 Ruby Platform には以下の制限や要望がありました。 最
もう 2018 年だけど, Jenkins + Docker + itamae + Serverspec でインフラ CI っぽいことをやってるのでメモ - ようへいの日々精進XP
やってること メモ Jenkins を動かす環境 Docker イメージ itamae レシピ Serverspec テスト Jenkins の準備 プラグイン Docker 周り ジョブ infra-itamae の設定 infra-serverspec の設定 動いてる図 Build Pipeline ログ 以上 やってること 今更かもしれないけど, ギョームで以下のようなことをやって, ここ数日で運用も回ってきた気がするのでメモしておく. itamae のレシピを amazonlinux コンテナに適用 適用したコンテナに対して Serverspec でテスト 1 と 2 を Jenkins のビルドパイプラインで流す 3 が正常に終了したら, pull request を作成, 又はマージ master ブランチのレシピをサーバーに手動で適用 Jenkins のポテンシャルと it
「Jenkins X」発表。Git/Docker/Kubernetesに特化したことでCI/CD環境の構築運用を自動化
「Jenkins X」発表。Git/Docker/Kubernetesに特化したことでCI/CD環境の構築運用を自動化 ソフトウェアの開発プロセスにおいて、「Jenkins」はビルドやテスト、デプロイなどを自動化してくれるツールとしてよく知られています。 そのJenkinsの派生プロジェクトとして、「Jenkins X」が発表されました。Jenkins Xは、Git、Docker、Kubernetesの環境を前提とすることで、Jenkinsの設定、運用などを大幅に自動化し、より簡単な導入と運用を実現するものです。 Jenkins Xは、Git/Docker/Kubernetes環境に特化 オリジナルのJenkinsは汎用的なビルドやテストの自動化ツールとして、さまざまな環境やツールと連係できるように作られています。そのため柔軟なコンフィグレーションが可能になっていますが、一方でそれが導入や
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
