DevOps

私はこれをサポートするために、DevOps変換プログラム内で適切な行動をとろうとしています。 問題とインシデント管理 容量管理 変更およびリリース管理 明確にするために、これらは運用組織に属していた機能であり、現在はアジャイル/ DevOps組織が所有しています。悪い動作を引き起こす既存のKPIは次のとおりです。 根本原因分析までの時間の完了： 不完全なRCAを時間どおりにシステムに取り込むために駆動します。 テスト実行時間： ビジネス価値に関係なく、長時間実行されるテストを無効にします。 クラウドサービスの平均使用率： 計算リソースのオーバーコミットを奨励し、結果として応答時間が遅くなります DevOpsプログラムで適切な行動を促すために使用できる主要業績評価指標は何ですか？

13 culture  metrics  kpi 

私は、Bambooからパラメーター化されたJenkinsビルドをトリガーして、以下を実行しようとしています： 役職 - http://jenkins-url.com/job/jobname/buildWithParameters?ENVIRONMENT=dev&APPLICATION=hello-world しかし、私はすぐに201を取得し、ビルドが作成されたことを知らせます。このリクエストを待機させて、火の代わりにビルドの成功ステータスを返すにはどうすればいいですか？ Parameterized-Remote-Trigger-Pluginごとに明らかに可能です： 編集：必要に応じてこれを最後に作成しました。 https://github.com/owenmorgan/jenkins-remote-builder

13 jenkins  jenkins-plugins  bamboo 

このシナリオを考えてみてください（実際の状況との比較はすべて偶然によるものです）： 3:07 am：サポートコールの着信「生産中の何かがダウンしました。あなたの助けが必要です！」。 午前3時12分：システムに接続（ログオン可）...コーヒーの時間はありません。 3:15 am：幸運なことに、すぐにどこかのエラーメッセージで問題を見つけることができます。 3:17 am：SCMツールボックスを使用してコードを取得し、問題を修正し、テストします。素晴らしい...私の修正は機能します！ 3:20 am：Dev Opsチームと連絡を取り、修正を出荷し、運用を再開します。 3:21 am：赤旗...「4つの目を尊重するには、この修正の承認を得るためにさらに2 つの目が必要です」。 3:22 am：ggggrrrreat、今何を、他に誰に電話すればいい（=マネージャーを起こす）？ 「四眼の原則の可能な実装（または例）とは？」に対する私の答えに似た承認手順を実装した場合、運が悪い...ここにあなたの選択があります： あなたの修正は、さらに2人の目が関与するまで行き詰まります（読んでください：生産が停止します）。 あなたは、失われた目を回避する方法を見つけ出します。 それでは、緊急修正のための4目原則をどのように実装するのでしょうか？...生産をできるだけ早く、つまり午前 3時25分頃に実行 できるようにするため...そして、通話を終了する（そして元の場所に戻る）こともできますか？

13 configuration  four-eyes 

アジャイルソフトウェア開発は、今日のソフトウェアショップが選択する方法論です。しかし、ソフトウェア開発でアジャイルを実践していない組織がまだあり、DevOpsの採用に関心があるかもしれません。 私がアジャイルソフトウェア開発と言うとき、私はアジャイルソフトウェア開発のための宣言から出てきたすべての子孫を意味します。以下のようなエクストリーム・プログラミング、スクラム、ソフトウェア開発リーンなどを。 アジャイルソフトウェア開発は、組織レベルでDevOpsを採用するための必須の前提条件ですか？

13 culture  agile 

私はAnsibleが初めてで、Chefでの経験があります。私は環境を管理するためにAnsibleを学び、使用することを検討しています。 AWSスポットインスタンスのインベントリを管理するためのベストプラクティスは何でしょうか？ たとえば、スポットインスタンスがシャットダウンされると、古いIPはホストのインベントリに関係なくなります。 弾力性のある環境のユースケースのために、他の代替アプローチはありますか？

13 ansible  amazon-web-services  amazon-ec2 

DevOpsとメインフレームに精通しているが、Jenkinsに不慣れな人がJenkinsを使い始めたいと思っているとします。例えば： メインフレーム上の個人ファイル（PDS、つまり区分データセット）に保存されているデータの管理の実行可能性を調査します（メインフレームソフトウェアを管理するために存在する一般的なSCMソリューションによって管理されていません）。 ある種の個人的な開発環境、たとえばVirtual BoxのLinux環境（それが理にかなっている場合）でJenkinsを実行する。 ある種（最小）のJenkinsのインストールと設定が完了すると、実際の質問は「Which of the typical Jenkins plugins, if any, would be needed?」になります。私の場合、理にかなっているように見えるさまざまなJenkinsプラグインから、これらは可能性のある候補であるようです（引用はリンクされたページからです）： IBM zOSコネクター。 ... IBM z / OS LPARへのFTP接続を介してその機能を提供します。z / OSでSCLMプロジェクトを構成してから、Jenkinsを介して変更を確認できます。 機能が含まれます： ユーザーJCLジョブの送信（終了時に収集されるオプションのログを使用）。 SCLMの変更をチェックアウトできるようにするプロジェクトのSCMとしてのSCLMの導入。 SCLMプロジェクトをビルドする機能は、現在、「Submit zOS Job」ビルドアクションを介してのみ実行できます。 Endevor、PDS、およびISPWプラグインのコンピュウェアソースコードのダウンロード。 ... Jenkinsユーザーは、Endevor、PDS、またはISPWメンバーをメインフレームからPCにダウンロードできます。その後、たとえばSonarQubeの分析とレポートのために、PCでソースにアクセスできます。 1番目のプラグインはSCLMに関するもので（PDSがすべてです）、2番目のプラグインはPDSのサポートを（その名前で）明示的に示しているため、両方が候補であると信じています。 私の候補リストが完全であると仮定すると（それですか？）、どちらが自分のケースに最適かを判断するのに役立つどちらかの長所と短所は何ですか？ Ps：「Jenkins Kickstart」パッケージのようなものは存在しないようです（少なくとも私はまだ見つけていません）。

13 jenkins  jenkins-plugins  mainframe 

frontend.imageJenkinsビルドスレーブに使用するDockerイメージがあります。Jenkins Dockerプラグインは、このイメージからコンテナーをスピンアップし、コンテナー内にアーティファクトを構築します。これはすべてうまくいきます。この場合、frontend.imageAngularJsアプリの構築に使用されます。このAngularアプリの構築の一部は、アプリに必要なnpmパッケージをインストールすることです。 このプロセス、npm installには時間がかかり、3分かかるようです。npmは常にすべてのパッケージを毎回インストールします。 そこで、スレーブ用のボリュームを追加しました。これはホストマウントボリュームです。Dockerプラグインは、フロントエンドコンテナーを実行するたびにこのボリュームを使用します。 コマンドを実行するユーザーnpm installはjenkinsです。npmは、npm config get cache出力するコマンドで見つけることができるキャッシュを保持します/home/jenkins/.npm その/slaves/volumes/tsl.frontend:/home/jenkinsため、Webコンテナのスレーブにホストボリュームをマウントしています。 Jenkinsプロジェクトを使用してAngularアプリをビルドします。問題なくビルドされ、多くのnpmパッケージがインストールされています。Dockerホストにsshしてcmd ls /slaves/volumes/tsl.frontendを実行すると、多くのnpmパッケージが表示されます。これは、スレーブのホストボリュームマウントが機能したことを意味します。 ここで、ジェンキンスプロジェクトをもう一度ビルドします。npmは、Dockerスレーブビルドコンテナがボリュームホストマウントを使用している場合でも、すべてのパッケージを再度インストールします。キャッシュされた多くのnpmパッケージを一覧表示するcmd docker exec -it <some_clever_random_container_id> bash、cmd su jenkins、cmd npm cache lsでスレーブコンテナーにバッシングすることでも確認できます。 そのため、ホストマウントボリュームにアクセス許可chmod 777があり、アクセス許可の問題がないnpm install場合でも、キャッシュを使用できません。 Dockerスレーブコンテナーを起動するJenkinsビルドで、最初に実行するcmdがnpm cache lsあり、多くのパッケージがリストされていますが、これはホストボリュームが期待どおりに機能し、npmキャッシュインデックスの整合性が壊れていないことを意味しませんか？ 通常のnpm installcmd を試しました。ローカルマシンで実行すると、最初にすべてのパッケージがインストールされ、次回はほとんどパッケージがインストールされません。また、このSOの回答とcmd npm --cache-min 9999999 installから取得したnpm cache "hack"npm --skip-installed --cache-min 9999999 install 関連する質問がStackOverflowに投稿されました。

13 docker  jenkins  npm 

Dockerレジストリから古い画像を削除する場合、エレガントな方法やベストプラクティスはありますか？ https://github.com/docker/docker-registry/labels/deleteに多くのリクエスト/問題がありますが、良い/人気のあるソリューションは見つかりませんでした。 だから、それをするのに役立つツールやテクニックはありますか？ また、実行中に従うベストプラクティスはありますか？

13 docker  toolchain 

「についての私の質問への受け入れ答えどのように継続的な統合は、連続配信/展開に関係していますか？」についても説明小さな違いの間に連続的送達と連続展開を。「本番環境にどのようにデプロイしますか。これらは（排他的な）選択可能なオプションです。」のような質問への回答に関連しているようです。 自動（マチック）。 マニュアル。 DevOpsの壁の向こう側に貧弱な「オペレーター」がいることを想像することはできません。 「質問」では、「配布」対「インストール」という参照は、そのような「手動」のものの可能な実装に近いですか？関連する質問の関連する引用は次のとおりです。 FTPのようなものを使用してターゲット環境に配布します（標準のコピーがギャップを埋めることができない場合）が、ターゲットでまだアクティブにしないでください。それが連続配信に似ている/近いはずなのか、そうでないのか？ バインド、停止/開始操作などのようなものと組み合わせて、いくつかのターゲット環境にインストール（またはアクティブ化）します。それは、継続的デプロイメントに似ている/近いはずですか？ 他の可能な実装は何ですか？

13 continuous-delivery  continuous-deployment 

「インフラストラクチャとしてのインフラストラクチャ」というフレーズは、過去2週間でさまざまな文脈で何度も言及されています。Infrastructure as Codeを持つことは、実際的な意味で実際に何を意味しますか？

13 terminology  infrastructure-as-code 

継続的な展開の1つの方法は、リリースから展開を切り離すことです。つまり、変更をすぐにアクティブ化せずに更新を展開します。 これには機能の切り替えを使用できることは知っていますが、「非機能」の他の手法があるかどうか疑問に思っています。 たとえば、バグ修正のために機能切り替えを作成しますか？おそらくそうではなく、バグ修正はできるだけ早く展開する必要があると主張することができます。そして、バグ修正がリリースされた後、それをオフに切り替えたくないことは確かです。しかし、これは事実ですか？制御された方法でリリースするのは危険な変更かもしれません。また、予期しない副作用がある場合は、ロールバックできると便利です。それでは、すべての変更に対する機能フラグはありますか？ そして、視覚的な変化はどうですか？たとえば、CSSの機能フラグのようなものを実装できますか？それは理にかなっていますか？

13 deployment  release-management  feature-toggles 

ApproximateNumberOfMessagesVisibleCloudWatchメトリックスのスケーリングポリシーを使用した一連のSQSキュー処理ジョブを担当しています。これらのジョブは、さまざまな理由で送信されたメッセージの量に追いつくことができません。 サービスの低下により、処理可能なメッセージの容量が減少します。 AutoScaling キューの深さが上昇し続けている間に最大制限に達しました。 S3の停止AutoScalingは、キュー処理ジョブが需要に対応するために使用する他の依存AWSサービス（サービス）に影響します。 技術チーム以外のチームメンバーと停止について話し合うとき、顧客から見える品質低下につながる可能性のあるキュー処理の特定の遅延を伝えたいと思います。SQSキューでこれを行うにはどうすればよいですか？

13 amazon-web-services  amazon-sqs  amazon-cloudwatch  post-mortem 

実行中のインフラストラクチャに関する詳細なメトリックを収集するために、Prometheusを監視ワークフローに徐々に統合しています。 この間、プロメテウスがデータをプルするはずのエクスポーターが応答しなくなるという奇妙な問題に遭遇することがよくあります。ネットワークの設定ミスが原因である可能性があります-アクセスできなくなっているか、エクスポーターがクラッシュしたためです。 理由が何であれ、Prometheusに表示されると予想されるデータの一部が欠落しており、特定の期間にわたってシリーズに何もないことがわかりました。1つのエクスポーターが失敗（タイミングアウト？）すると、他のエクスポーターが失敗することもあります（最初のタイムアウトがジョブ全体をトップレベルタイムアウトより上に押し上げましたか？ただ推測しています）。 上記の視覚化で示されているように、私が見るのはシリーズのギャップです。これが発生した場合、ログには何もありません。プロメテウスの自己計量もかなり不毛のようです。プロメテウスがやっていることを手作業で再現し、どこで壊れているのかを手作業で再現しようとする必要がありました。これは面倒です。もっと良い方法があるはずです！リアルタイムアラートは必要ありませんが、少なくとも、エクスポーターがデータを配信できなかったことを確認できるようにしたいと考えています。ブール値の「データを確認してください」というフラグでさえも始まりです。 輸出業者からデータを取得できなかったプロメテウスに関する意味のある情報を取得するにはどうすればよいですか？Prometheusデータ収集の手動シミュレーションを実行せずにギャップが存在する理由を理解するにはどうすればよいですか？この点に関して、おそらくプロメテウスを超えてデータ収集全般の監視に拡張された場合でも、賢明な慣行は何ですか？

13 monitoring  prometheus 

青緑の展開では、緑の環境をライブで展開するための準備として、ライブのprodデータフロー（青）をホットスワップの非prod環境（緑）にポンピングし、緑が以前の青のprod環境と完全にデータ同期するようにします。 進行中のWebSocketトラフィックを青から緑にライブコピーするために人々が何を使用しているのか疑問に思います。独自のWebSocketライブラリを作成しますか、または青緑へのパブリッシュ/サブスクライブWebsocketライブラリがありますか？ 私のアプリにはnodejs RESTサーバーがあり、モバイルデバイスからのwebsocketトラフィックも管理しています... mongodbサーバーなど...それぞれGCE / AWSのコンテナにあります 私はちょうどmongodbを青から緑に同期させることができることを理解していますが、それは私が探している素晴らしい回帰健全性チェックであるライブトラフィックで緑のnodejsサーバーを行使しません おそらく、HTTPトラフィックをライブ転送するだけで、HTTPの上で実行される基礎となるWebSocketがそれ自体を処理し、特定の青緑の設定を要求しない可能性があります

13 deployment  bluegreen  http 

停止しているコンテナや、起動後に非常に速く停止して停止するコンテナを調査する必要がある場合があります。 docker exec -ti <id> bash 実行中のコンテナでのみ機能し、終了すると、bashプロンプトも終了します。 ではdocker start、あなたは別のコマンドを供給することができない、とコンテナが突然再び死ぬ場合は、コンテナに入ると、あなたの調査を行うのに十分な時間がありません。 我々は行うことができdocker commit、その後、docker run別のコマンドを使用して新しいイメージではなく、他の選択肢がある場合、私は思ったんだけど。 注：docker logs印刷されたアプリをstdout / stderrに返すだけです。それは問題が何であったかを理解するのに十分ではないかもしれません。

13 docker  containers  post-mortem