お久しぶりです。コンサルタントの森 (@mosuke5)です。 コロナで自宅勤務の人も多いかと思いますが、みなさんどう過ごしていますか？ ずっと家にいると辛いので、定期的に息抜きで家の散歩をしています。桜もちょうどきれいでいい花見？になります。 さて、ここ最近は、OpenShift上でのCI/CDパイプラインの構築をたくさん行ってきたのですが、 よくある質問に「どうやってカスタムのJenkins agentを作ったらいいか」がありました。 まとまった情報もインターネットになかったので今回書いてみました。 デフォルトのJenkins agentイメージ OpenShiftのインストール後のデフォルトでもmaven環境とnodejs環境のagentのイメージがあります。(OCP 4.3環境) openshiftプロジェクト内にあるimage streamを確認してみます。 $ oc get i
Red Hat で OpenShift のコンサルタントをしている id:hashnao です。 赤帽エンジニア Advent Calendar 2018 - Qiita 12日目の記事です。 今日は既に13日目ですが、気にせずリリースしていきます。 イメージのビルド方式 OpenShift Jenkins Pipeline (DSL) Plugin とは OpenShift Jenkins Pipeline (DSL) Plugin のチュートリアル Reference OpenShift Jenkins Pipeline Tutorial, Sample イメージのビルド方式 OpenShift では OpenShift 上でコンテナイメージをビルドする際、複数のビルド方式 をサポートしています。 BuildConfig にイメージのビルド方式を定義したり、 oc new-build
OpenShiftに組み込まれたJenkinsは、パイプラインビルドを開始したときにコンテナをOpenShift上に起動し、その上でパイプラインを実行します。 このようなJenkinsからビルドするために起動、破棄されるコンテナをAgentコンテナとかSlaveコンテナとか呼ぶようです。 このAgentとして使われるコンテナイメージは簡単に追加、変更できるのですが、方法がいまいち分かりにくいというか目立たない気がするので紹介させてください。 ここでは、hugoを使って静的なサイトをOpenShiftのJenkinsでビルドする想定で、hugoがインストールされた以下のコンテナイメージをJenkinsのagentとして使用します。 https://github.com/literalice/agent-hugo/blob/master/Dockerfile # We are basing o
OpenShiftに機能の一部として同梱されているJenkinsですが、デプロイ時に環境変数を指定することで好きなJenkinsプラグインを追加することができます。 https://docs.openshift.com/container-platform/3.10/using_images/other_images/jenkins.html#jenkins-environment-variables 指定するのは、以下の二つの環境変数です。 OVERRIDE_PV_PLUGINS_WITH_IMAGE_PLUGINS Jenkinsプラグインが保存されているPVへ、Jenkinsのコンテナからプラグインを上書きコピーするかどうか。 false(デフォルト)の場合、Jenkinsが初回に起動したときしかプラグインがコピーされない。 例： true INSTALL_PLUGINS OVERR
【一般参加】9/23 12:00～ Jenkinsユーザ・カンファレンス 東京 2018 参加費は無料です。 お申し込みは「 Jenkinsユーザ・カンファレンス 東京 2018」Tokyo Jenkins Area Meetupからお願いします。 【懇親会】9/23 18:30～ Jenkinsユーザ・カンファレンス 東京 2018 「Jenkins ユーザカンファレンス 2018 東京」の懇親会のご案内です。 お申込みは「【懇親会】9/23 18:30～ Jenkinsユーザ・カンファレンス 東京 2018」からお願いします。 会場：北の味紀行と地酒 北海道 飯田橋駅前店 時間：18:30～20:30 住所：東京都新宿区神楽河岸1-1 セントラルプラザビル20F 会費：4000円 ※費用は当日スタッフにお渡し下さい。 【LTのスピーカ枠】Jenkinsユーザ・カンファレンス 東京 20
TL;DR AWS CodeBuildとJenkinsを連携させると、これまでJenkins Agentで実行していたビルド処理をAWS CodeBuildに置き換えることができます。以下のメリットがあります。 AWS CodeBuildは無限に*1スケールするので、ビルドキューの待ち行列がなくなる ビルド単位で課金されるので、Jenkins AgentのEC2インスタンスを待機させておくコストが不要になる コンテナでビルド処理が実行されるので、ビルドに必要なOSやミドルウェアを管理する手間がなくなる JenkinsのUIやユーザ管理をそのまま使い続けられるので導入しやすい AWS CodeBuildとJenkinsを連携させるには公式の AWS CodeBuild Plugin を利用します。 AWS CodeBuildとJenkinsの連携はGitHubだけでなくGitBucketやG
あけましておめでとうございます。ソフトウェア開発をめぐる環境は相変わらず日進月歩です。この変化に伴って、ソフトウェア開発そのもののあり方も変化を続けています。本稿では、少し大きな視点から継続的インテグレーション（CI）・継続的デリバリ（CD）の最近の動向を紹介します。 CI/CDの大きなうねり 筆者がJenkinsに携わって12年になります。かつて、CI/CDの取り組みは、現在の機械学習やスケールアウト技術のような将来の可能性が注目される若い技術でした。ここ数年、この若い技術は、広く産業界で大規模に組織がかりで展開される成熟した技術に変貌してきました。 この背景にあるのは、ソフトウェア開発・運用全般における自動化のさらなる浸透です。このような自動化の進展は2つの側面から考えることができます。一つは、ソフトウェア開発に必要な様々な作業それぞれの「部品の自動化」という側面です。もう一つは、
（この記事は、CloudBees社 Blog 「Opinionated Kubernetes and Jenkins X」2018年3月18日 Michael Neale 投稿の翻訳記事です。） 先日、あらゆるクラウドプラットフォームがKubernetesに集結し、開発者も同様だという記事を書きました。とてもエキサイティングな時期を迎えていますが、反面、多くの人にとって問題となるのは、アプリケーションをどうビルドしてデプロイするかについて、まだまっさらの大きな白紙であることです。これは空白、無であり、無限の可能性を秘めたキャンバスです。 問題は、想像がつくと思いますが、何も描かれていないキャンバスでゼロから始めることが本当に好きな人、また始められる人はほとんどいないということです。私自身も、何か既にあるものから作業を開始し、解決に向かって試行を繰り返すか、あるいは何か指針となるレールがある
「Jenkins X」発表。Git/Docker/Kubernetesに特化したことでCI/CD環境の構築運用を自動化 ソフトウェアの開発プロセスにおいて、「Jenkins」はビルドやテスト、デプロイなどを自動化してくれるツールとしてよく知られています。 そのJenkinsの派生プロジェクトとして、「Jenkins X」が発表されました。Jenkins Xは、Git、Docker、Kubernetesの環境を前提とすることで、Jenkinsの設定、運用などを大幅に自動化し、より簡単な導入と運用を実現するものです。 Jenkins Xは、Git/Docker/Kubernetes環境に特化 オリジナルのJenkinsは汎用的なビルドやテストの自動化ツールとして、さまざまな環境やツールと連係できるように作られています。そのため柔軟なコンフィグレーションが可能になっていますが、一方でそれが導入や
OpenShift 全部俺 Advent Calendar 2017 Google Home買いました。日本語設定でいろいろやってみて、3歳児が「おーけーぐるぐる、てべりをちゅけてください、おねがいします！」と話しかけてるのを一通り楽しんでから英語設定にスイッチして使ってます。これで子供が英語覚えたりするかな。まぁしないだろうな。 前回Jenkins PipelineジョブをSlaveとなる別のPodで実行しました。今回はこのslave podをカスタマイズしてみましょう。ドキュメントは以下のURLです。 https://docs.openshift.org/3.11/using_images/other_images/jenkins.html https://github.com/jenkinsci/kubernetes-plugin config.xmlにデフォルトの定義mavenとn
こんにちは。アプリケーション共同開発部の門多です。 昨年の終わり頃に、 Mac mini 増殖中！iOS アプリのビルドをマスター・スレーブ化して時間を短縮するという pixiv さんの記事がありましたが、フェンリルの共同開発事業アプリ開発でも、2012 年ごろから Jenkins を使ったビルドを行っています。 なるべく多くの人に使ってもらえるように、基本的に制限しない運用を行なっていました。しかし数年経ってみると、OS やビルド環境の変化もありましたし、現在の構成が色々と問題を起こしていることもわかってきました。現在ビルド環境の改善を行っているので、ついでに Keychain 管理の自動化や Xcode 自動インストールなど、これまで経験した色々な問題とその対応方法をまとめました。かなり長い記事になってしまいましたが、実際に使っているプログラムをそのまま掲載していますので、そのうち一部
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
コンテナCIとJobの管理方法について話してきた。 話した内容や質問された内容を補足する。 スライドはこちら。 コンテナCIの流れ ありがちではあるが、以下の通り。 GitHubへ変更内容をPush or PRのコメント欄にtest this pleaseと記述 上記のイベントをトリガとしてJenkinsのJobが実行 試験内容はJenkinsではなく、Kubernetes上のコンテナで実行 試験結果をSlackに通知する 環境構成 図は、分かりやすさを優先してだいぶ省略している 試験の目的は、OpenStackの1コンポーネントに対して入れた修正の動作確認。 そのため、他のコンポーネントについては基本修正が入らない。 修正が行われるコンポーネントのみコンテナ化して、他のものはVM上に固定で作っている。 これは、コンテナ化には初期コスト&起動時間を回避するためだ。 VMはOpenStack
ジョブの設定をJenkinsfileで管理し始めてから3か月ぐらい経ったので、知見をまとめてみます。 Jenkinsfileを使うメリット Jenkinsの画面でジョブを管理していると以下のような問題が起きることが多いと思います。 誰かが勝手にJenkinsの設定を変更して動かなくなった ジョブ設定を別リポジトリに横展開したいけど、ポチポチ設定するのが面倒 JenkinsfileをGitで管理することで、以下のメリットがあります。 いつ、誰が、なぜジョブ設定を変更したのか後から調べられる Pull Requestでジョブ設定の変更をレビューできる ブランチを使ってジョブ設定を試行錯誤しやすい Jenkinsの運用ポリシー 前項のメリットを実現するには、Jenkinsを以下のポリシーで運用することが望ましいでしょう。 Jenkinsの設定は最小限に抑える なるべく画面からジョブ設定を変更せず
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
