DevOps

自動テスト、継続的デリバリー、サービス統合と監視、およびSDLCインフラストラクチャーの構築に取り組んでいるソフトウェアエンジニアのためのQ&A


4
宣言型パイプラインを使用して動的な並列アクションを適切に実現する方法は?
現在、ディレクトリ内のすべてのファイルを検索し、見つかったすべてのファイルに対して並列タスクを開始する必要がある実装が必要になります。 宣言的なパイプラインを使用してこれを達成することは可能ですか? pipeline { agent any stages { stage("test") { steps { dir ("file_path") { // find all files with complete path parallel ( // execute parallel tasks for each file found. // this must be dynamic } } } } } } }

4
異なるコンテナでnginxとphpをドッキングすることの利点は何ですか?
私はDockerとKubernetesで作業を始めたばかりで、多くのスタックを見てきました。一部の人々は単一のイメージでnginx + phpを構築し、一部はnginxで画像を構築し、別の画像はphpで構築します(同じパスをマウントしてKubernetesの同じ展開内の両方のコンテナ)。 両方のnginx + phpを同じものにインストールする代わりに、2つのdockerイメージを構築する利点は何でしょうか?


4
エンジニアがコードを展開および実行するときに、職務分掌を可能にするプロセスまたはツールは何ですか?
金融サービス部門などの規制の厳しい環境では、職務分掌は開発責任と生産特権を持つ個人間の衝突を回避するための不可欠なメカニズムです。 従来、これは開発者がコードを開発してから運用に引き継ぐことを意味していましたが、多くのDevOpsオペレーティングモデルでは、開発と運用の分離は少なくともぼやけています。 Googleのサイト信頼性エンジニアリング(SRE)では、Google内に個別のSRE機能がありますが、開発者は、運用負荷が高いときにSREをバックストップするために持ち込まれます。 で「あなたはそれを構築し、あなたを実行それ」モデルは個別の操作機能はありません。 職務分離メカニズムの根本原因を数か月にわたって掘り下げた後、Sarbanes Oxleyセクション404:内部統制の管理評価を満たすために主に存在するようです。 (a)必要なルール。委員会は、1934年証券取引法第13条(a)または15条(d)で要求される各年次報告書に、内部統制報告書を含めることを要求する規則を規定します。 (1)財務報告のための適切な内部統制構造と手順を確立および維持するための経営者の責任を述べる。そして (2)発行者の直近の会計年度末の時点で、財務報告のための発行者の内部統制構造と手順の有効性の評価を含む。 (b)内部統制の評価と報告。サブセクション(a)で要求される内部統制評価では、発行者の監査報告書を作成または発行する各登録会計事務所は、発行者の経営者が行った評価を証明し、報告しなければなりません。このサブセクションに基づいて行われた認証は、理事会によって発行または採用された認証契約の基準に従って行われるものとします。そのような認証は、個別の契約の対象にはなりません。 コメントに基づいて、私が行っているいくつかの仮定を呼び出すことが重要です。 私は主に大規模市場の金融サービスを検討しています。つまり、取引量は多いが比較的低い価値です。これは、異なる取引価値プロファイルを持つ商業金融サービスとは対照的です。 金融機関のオンラインサービスは、さまざまなリスクを考慮した多くのコンポーネントで構成されます。 Move Money-アカウント間でお金を移動したり、異なる所有者のアカウント間で送金したりします。いくつかを挙げると、マネーロンダリング防止、詐欺防止、および禁輸国を考慮しなければならない作業。 顧客獲得 -Move Moneyに比べて取引量が少ないため「リスク」が少ないが、まだ検討が必要です。 インターネットバンキング -さまざまなレベルのリスクを伴う幅広いサービスをカバーしています。MoveMoneyはその一部と見なされます。 リスクに応じてそれぞれに異なるアプローチをとることが考えられますが、単純にするために、最もリスクの高いオペレーションの一部に適用されるソリューションに取り組んでいます。 TL; DR:証券取引委員会の 規制に準拠する適切な内部統制を確保することは、経営者の責任です。 Sarbanes Oxley 404は通常、トップダウンリスクアセスメントを完了することで満足します。その一部は共謀のリスクを評価し、緩和戦略を進めます。 開発者が日常的にソース管理と生産の両方にアクセスできるDevOpsのプラクティスと文化を採用している会社内で、職務分掌を達成する方法、またはより一般的には結託のリスクを軽減する方法。



4
アーティファクト(またはアーティファクト)とは何ですか?
「アーティファクトリポジトリとは」に関する質問には、そのリポジトリの部分に関する興味深い説明を含む回答が含まれています。そして、答え全体を読んで、DevOpsのコンテキストで「アーティファクト」が正確に何を意味するのかわかりません。 助言がありますか? 追伸:答えの1つから、おそらく人工物が私が疑問に思っている(混乱している)ことを理解しているようです...

2
複雑な並列Jenkinsパイプラインを構築する方法は?
私は、Jenkinsの特注の統合をパイプラインに変換することに興味がありました。しかし、私はそれを行う方法を理解できないようです。 誰でも次のことができるJenkinsスクリプトで私を助けることができますか? 1---2---3-----------9---10 | | |---4-------| | | |---5---6---| | | |---7---| 1: Start pipeline 10: End pipeline 5: Build some files * needed by 6, 7, * needed as artifacts at the end 2, 3, 4, 6, 7: Have jUnit result files, should be available at end of test …

2
DevOpsコミュニティで書籍がそれほど普及しているのはなぜですか?
私は、時間の経過とともにますます多くの本を推奨するブログのかなりの数を見てきました。 私はフィクションを読むのが好きで、本に対する嫌悪感はありませんが、通常これらの本で技術が動いたときにブログ投稿を更新/書き直すことができます。 DevOps関連のタイトルには、オンラインの世界にはない特定の品質がありますか?
17 culture 

3
SCMでレポを複製しないようにJenkinsジョブを設定します
Bitbucket Pluginを使用してJenkinsとBitbucketを統合しました。プラグインのWikiに従って、リポジトリがジョブのSCMに設定されている場合、特定のジョブがトリガーされます。ご存じのように、JenkinsジョブでSCMを設定すると、ビルド前の段階でこれが複製されます。 ここまでは順調ですね。ただし、設定しているジョブの主な目的は、リポジトリのコンテンツとは関係ありません。代わりに、Bitbucketから送信されたペイロードをジョブで処理するだけです。リポジトリをクローン化することは、本当に必要ないにもかかわらず、ストレージに関しては大した問題ではないと言えます。そうは思わないので、不必要な手順を追加し、時間とリソースを消費することは良い習慣ではありません。 質問は次のとおりです。JenkinsジョブでSCMを設定する方法を知っているが、リポジトリのクローンを作成することはできませんか?
17 jenkins 

2
「機能フラグトグル」とは何ですか?また、いつ使用する(またはしない)のですか?
についての質問がいくつかありますfeature flag toggles。 機能フラグトグルの使用を開始するように開発者を説得する方法 機能フラグトグルの使用方法 私の質問: (DevOpsのコンテキストで)実際に「機能フラグトグル」とは何ですか? なぜ使用されるのですか?

6
データベースの継続的な展開を可能にするプラクティスまたはツールは何ですか?
インフラストラクチャとコードの継続的配信または継続的展開は、データベース、特にRDBMSに対して同じアプローチを試みるのに比べて比較的簡単です。コードとインフラストラクチャは、展開が完了しても変更も進化もしません。ただし、データベースには新しいデータが追加され、スキーマが本質的に可変コンポーネントでない場合、データが作成されます。 データベースオブジェクト、つまりテーブルと列のみを追加し、それらを変更または削除しないなどのプラクティスがあることを認識しています。スキーマ。 同様に、FlywayやReady Rollなど、スキーマのバージョン間で記述される移行の記述を支援する製品があります。 現在、データの整合性が懸念される本番環境へのデータベーススキーマの継続的な展開を可能にする他のプラクティスとツールはありますか?


2
アプリケーション構成はどこに置くべきですか?
私は最近、「環境に依存するプロパティをどこに保存すべきか」という議論を読んでいます。 従来の方法は、環境ごとに複数のプロパティファイルを作成し、環境変数(DEV、PROD ...)に基づいて、アプリケーションの起動時にそれらを読み込む場所を選択することです(Springプロファイルなど)。 一方、コンテナを使用してアプリケーションを展開している場合、この種の構成は環境自体から(アプリケーションが読み取る環境変数を使用して)取得する必要があるため、イメージは環境間で変化しません。 各アプローチの長所と短所は何ですか?コンテナシナリオに「最適な」アプローチはありますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.