DevOps

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

3
なぜビルドサイズがそんなに心配なのですか?
「ビルド/スラッグのサイズが大きい」とよく聞かれます(人々からだけでなく、有益なCLIからも)。これは特に、ビルドのサイズが0.5〜2 GBの場合に当てはまります。 なぜ(またはどのような状況で)ビルドサイズがこのような懸念事項なのですか? 注:私が尋ねる理由は、ストレージやコンピューティングなどのリソースが以前に比べて比較的安価であると考えているためです。したがって、どちらかと言えば、ビルドサイズは以前ほど問題にはならないと思います
8 builds 

4
勤務先の会社の本番環境へのアクセスをどのように制限しますか?
私が働いている会社では、devospsエンジニア(現在、私と同僚の2人のメンバーのみ)が、本番データベースにアクセスできる唯一の人です。 したがって、他の開発者が本番データベースでMySQLクエリを実行する必要がある場合。彼らはクエリを2人のエンジニアに送信して実行させます。 本番データベースに対してコマンドを実行する必要がある状況は次のとおりです。 データベースには破損したデータが含まれているため、バグが発生します。バグを修正するコマンドを実行します。 バグが報告されています。また、データベース内の現在の値を確認したいと考えています。 ある顧客が自分のデータを変更したいと考えています。しかし、私たちのWebアプリケーションには変更を行う機能がありません。したがって、MySQLコマンドをデータベースに直接送信して、顧客の要件を完了する必要があります。 QAチームは、運用環境でテストアカウントを作成しました。また、他のテストを実行できるように、アカウントのステータスを変更したいと考えています。 これにより、他の同僚に多くの中断が生じます。日中にプログラムを開発する場合、クエリを実行するためだけにコンテキストを切り替える必要があることがよくあります。 これは会社にとって良いアーキテクチャではないと思います。会社の本番環境へのアクセス許可をどのように制御しますか? 私たちの生産データベースは、機密の顧客情報で構成されています。データが漏洩した場合、当社は数百万ドルの罰金を科される可能性があります。

3
開発者は、プッシュ後にCIパイプラインが完了するのを待つか、次のタスクを開始する必要がありますか
私の会社はCI / CDを統合しています。これまでのところ、私が理解しているものからCIを実装しています。現在、開発者がコードをgitリポジトリにプッシュすると、CIパイプラインが実行されます。 現在、CIパイプラインには、プロジェクトの構築と静的コード分析の実行が含まれており、コーディング標準に適合していることを確認しています。次にテストを実施します。ビルドと静的コードの分析には、現在約3分かかります。私が読んだことからすぐに問題を修正することは、CI / CDにとって重要です。単体テストを追加すると、パイプラインの実行に約10分かかることが予想されます。 したがって、私の質問は、CIパイプラインが完了するのを待つか、次のタスクに進んでパイプラインの問題が存在する場合はそれを修正するためにプル/マージリクエストを行う必要があるかということです。または、座ってパイプラインの実行を監視する必要がありますか?

1
マイクロソフトによるGitHubの買収により予想される影響は何ですか?
github.comにアクセスすると、MicrosoftがGithubを買収したことが発表されました。 複数のプロジェクトがgitlabやbitbucketなどの他のgitプロバイダーに移行されたという噂があります。この買収はDevOpsの観点からどのような影響がありますか。具体的には、TravisとGitHubの統合はそのまま使用できますか?心配する必要がありますか?たとえば、ユーザーはGitHubを使用するためにライセンスを購入する必要がありますか?travisci統合は無視されますか?

2
コマンドラインからJenkinsfileを実行する方法はありますか?
Jenkins UIを使用したくない、代わりにコマンドラインを使用したい。コマンドラインからJenkinsfileを実行して、Jenkinsサーバーに対して実行したい。 これは可能ですか? Jenkinsfileがあるとしましょう。Jenkinsfileを実行すると、JenkinsサーバーからJenkinsfileが実行されます。ジョブがJenkins UIを介してまだ構成されていないと想定します。

3
Python Webアプリケーションを作成する1人の開発者にとって、良いdevopsアプローチは何ですか?
一部の読者にとってこの質問は信じられないほど些細なことのように思われますが、開発者であるが、マニュアル以外の方法でアプリをデプロイした経験がほとんどない人としては、ある意味で、期待どおりに、それが理解できることを願っていますさまざまなアプローチやツールの数を確認するのは非常に難しいので、正しい方向に進むために少しアドバイスをすることができました。 私は開発者ですが、今は限られた時間の中でのみです。これまで私はJavaを使用してWebアプリケーションを構築しており、warファイルをTomcat環境にデプロイして、物事を適切にカプセル化しておくことにかなり満足しています。 私は現在PythonとDjangoで作業していますが、デプロイする必要があるポイントに近づいたら、できる限り自動化し、確実にデプロイできるようにするための確固たるdevopsワークフローをセットアップしたいと思いますが、使用例は比較的単純です。自分のニーズに合わせて過剰に設計され、時間の多大な投資を必要とする大きな脂肪のツールセットを学習したくないので、アプリのコーディングを使用します。 ですから、大きな開発エコシステムのセットアップと学習に膨大な時間を費やすことなく、確実にアプリをデプロイして管理することができる中立的な立場を探しています。 さらに詳細... 環境 Macで開発し、PyCharmを使用してDjango 2、Python 3をビルドしています。 ソフトウェアのバージョン管理にはgit(githubではない)を使用しています。 私は他の言語やスクリプト言語に慣れており、bashはあまり好きではありませんが、いくつかの(おそらくかなりアマチュアっぽい)bashスクリプトを書いています。私はPerlにも手を出しましたが、これは実際には手を出すための言語ではないことに気付きました(つまり、適切に学習するために時間を費やす必要があります)。 VPS環境、おそらくDigitalOceanに展開するつもりです。 私のアプリはミッションクリティカルではありませんが、サイトがダウンした場合、それがアプリを再起動するか、サーバーを再起動するか、別のサーバーに移動するかにかかわらず、ダウンした場合に確実に回復する方法が必要です(またはその他)。 特定の要件 アプリを受け取るための新しい環境をセットアップする機能。 これまで私が学んでいる間、これは手動で行われ、それを行うたびに、新しいDropletをゼロから始めました。これをはるかに単純化(自動化)して、緊急時に新しい環境をセットアップしなければならない場合でも確実に行えるようにしたいと思います。 可能な限りライブと同じステージング環境にアプリをデプロイする機能。理想的には、継続的インテグレーションアプローチを使用してgit pushによってトリガーされる自動化プロセス(これまで行ったことがない)と同じです。 ステージング環境でのアプリに満足したときに「ボタンを押す」機能。理想的には自動的にライブ環境にプッシュします。 サイトを監視する方法(ページへの投票だけで十分です) ライブサイトでアプリまたはサーバーの障害から回復する必要がある場合に、ライブサイトを別のサーバーに切り替える方法。青緑のアプローチがうまくいくと思いますか? 何を試したり検討したりしましたか? Djangoアプリを使用してライブ環境を手動で設定し、変更があった場合は新しいコードベースを手動でコピーします。これは人為的なミスが発生しやすいと感じており、デプロイでミスをすると回復不可能なエラーが発生することを恐れています。 Docker。Dockerについて知ったときは夢が叶ったように思えますが、少し実験と研究を行った後、これを実行して管理するためにどれだけ多くのことを学び、知る必要があるかに悩んでいます。いったん機能するようになるとリスクは非常に低くなるので、これは価値があるかもしれませんが、現時点では、私が期待しているよりも大きな時間を投資しているように感じます。 Bashスクリプト。それらを使用して、元の環境をセットアップし、アプリの更新などの特定のタスクを実行します。これについての私の心配は、スクリプトがテストを必要とするコードになることであり、この方法で信頼できるツールセットを構築するには多くの時間がかかるのではないかと心配しています。 私は、フローティングIPアドレスに関するDigital Oceanのオプションと、かなり賢明なように見える「ブルーグリーン」アプローチのために2つのサーバーを使用する機能を見てきました。このルートに進んだ場合でも、展開を自動化できる必要があります。 だから...私は、リスクの最小化(例:更新によってライブアプリが破損するリスク、または障害から回復できなくなるリスク)と時間の最小化の間の適切なバランスを見つけるdevopsアプローチに関するアドバイスを探しています環境とワークフローをセットアップするために必要な投資。


2
Ansible Playbookテンプレートでsudoersファイルを変更する
私はansibleテンプレートでsudoersファイルを作成しようとしています。sudoersファイルは次のようになります。 Cmnd_Alias LS = /bin/ls Cmnd_Alias LESS = /usr/bin/less Cmnd_Alias DU = /usr/bin/du %support1 ALL=(ALL) NOPASSWD: LS, LESS, DU これまでに管理したことは以下のとおりです。 Cmnd_Alias LS = ls Cmnd_Alias LESS = less Cmnd_Alias DU = du %support1 ALL=(ALL) NOPASSWD: LS, LESS, DU テンプレートは次のようになります。 {% for item in commands %} Cmnd_Alias {{ item|upper }} = …
8 ansible 

1
Tillerを高可用性にする方法は?
helmを使用してサービスをKubernetesクラスターにデプロイしています。 ティラーポッドのサービス可用性を向上させたい。そこで、ティラーのデプロイを2つのレプリカにスケーリングしました。 Helmは以前と同様に機能しており、これに関連する問題はありません。 誰かが舵と分げつの信頼性を高めるためにこれが良い考えではないかもしれない理由を誰かが持っていますか? 編集: Helm v3は、分げつの使用を減らす予定です。この問題を無関係にする helm v2で耕うん機を使用しないエクスペリエンスが必要な場合は、helm- tiller プラグインを使用できます。

2
べき等性と不変性の比較
DevOpsの多くは、不変のインフラストラクチャを実装し、変更が必要な場合に(変更するのではなく)再展開することで、ペットではなく牛の考え方を適用しています。 構成管理には、べき等の同様の原則があります。不変性と無力の比較の利点、類似点、欠点は何ですか?どちらがより効率的ですか?これらを相乗的に使用できますか(例:構成管理を使用したVMまたはDockerコンテナーの定期的な削除と再デプロイ?)

2
Dockerfileの代わりに構成管理ツールを使用しないのはなぜですか?
私はDockerと構成管理ツールにかなり慣れています。 最初はbashスクリプトの作成を開始して、開発マシン用のVagrantボックスをプロビジョニングしましたが、今はそのためにChefを使用するように切り替えました。同じソースを使用して、開発環境と本番環境の両方をプロビジョニングし、同じようにそれらを試して取得できるようになりましたできるだけ。 Chefを使い始めてから、シェルスクリプトの行をプロジェクト間でコピーして貼り付ける必要がないというDRYの側面、1つの統合されたソースを使用してさまざまなLinuxディストリビューションを実行するマシンをプロビジョニングする機能、および便利さを楽しんだコミュニティ提供のクックブックを使用する方法。 Chefを使用してvmをプロビジョニングしているので、RUNコマンドに続いてシェルコマンドをDockerfileに追加してChefレシピを実行するだけで達成できることを達成するとき、後退するような気がします。 私はググって何も見つかりませんでした(しかし、たぶんそれを逃しただけかもしれません)が、Dockerコンテナーを構築するChefレシピを使用する簡単な方法があるようには見えません。何故ですか? コンテナは不変であることを意図しており、構成管理ツールは通常、マシンの寿命全体でマシンを再構成するために使用されますが、コンテナの最初の構築中に使用した場合でも、多くの利点を提供しませんか?

2
DevOpsに対する一般データ保護規則(GDPR)の影響は何ですか?
一般的なデータ保護規制(GDPR)は、欧州市民に関するデータの保護を改善するためのルールのセットです。このリンクからの引用: EU一般データ保護規則(GDPR)は、20年間でデータプライバシー規則の最も重要な変更です。 GDPRの主な変更点の概要、特に次のようなデータ主体の権利については、GDPRの主な変更点をご覧ください。 違反通知。 アクセス権。 忘れられる権利。 データの移植性。 デザインによるプライバシー。 ... GDPRに関するいくつかの事実: GDPRは2018年5月25日から施行されます(これはかなり近いです)。 GDPRの主要な変更からの引用(地域の範囲について): ... EUで処理が行われるかどうかに関係なく、EUのコントローラーおよびプロセッサーによる個人データの処理に適用されます。GDPRは、EUで確立されていないコントローラーまたはプロセッサーによる、EU内のデータ主体の個人データの処理にも適用されます。ここでの活動は、以下に関するものです。EU市民への商品またはサービスの提供(支払いが必要かどうかにかかわらず) EU内で行われる行動の監視。EU市民のデータを処理する非EU企業も、EUの代表を指名する必要があります。 Y2Kを覚えるのに十分な年齢の人なら誰でも、90年代に誇大宣伝(ITシステムへの影響)を考えてみてください。これらのY2Kの問題すべてに対処するIMHOは、このGDPRの課題に比べて簡単なものでした。 質問:GDPRがDevOpsに及ぼす影響は何ですか? GDPRに準拠させるには、DevOps ツールチェーンでどのような変更が必要ですか? 90年代にSCMツールがY2K準拠になるのを助けたのと同様に、DevOps実践はどのようにして企業がGDPR準拠になるのを支援(促進、簡素化など)できますか?

2
データサイエンスパイプラインとモノリティックモデルblob
通常、DevOpsの重要なトピックの1つは、ソフトウェアアーティファクトの自動作成と配信をどのように処理するかです。 データサイエンスの台頭により、新しいタイプのアーティファクトが存在します。たとえば、訓練されたニューラルネットや他の機械学習モデルを表すモノリティックバイナリブロブです。このようなblobはサイズが数GBになる可能性があり、その作成は組織をCI以前の時代に戻す標準化されたAFAIKにはまだなっていません。それにもかかわらず、彼らは自分のバージョンと関連するトレーニングデータのコレクション(コーパス)を持っています。これらは急速に成長する傾向があります。 DevOpsメソッドを使用してこの新しい課題に対処するためのベストプラクティスは何ですか?

2
Dockerイメージの暗号化(エンドツーエンド); オフラインチャネルでの転送
私たちはイントラネットでDockerイメージを開発および構築しており、私たちに属するいくつかのホスト(開発者、内部テスト、外部テストなど)にそれらを展開する必要があります。これらの一部はイントラネットにあり、一部はインターネットでサードパーティがアクセスできます。 最終的な展開は、いくつかのノード(実稼働、さまざまなテスト段階)上の顧客のイントラネット内です。これらはファイアウォールの背後にあり、イントラネット外の物に定期的にアクセスすることを許可していません。つまり、デプロイメントのために外部レジストリへのアクセスを許可できるものもあれば、不可解なソフトウェアのアップロードを通じて手動で画像を配信する必要があるものもあります。ツール。 画像を暗号化して保存できる(できればGPGまたは同様の、単純なパスワードではない)インターネット上のレジストリ(おそらく、そこにあるVMで自分で実行した可能性があります)を持つ方法を探しています。しかし、その場合は、手動でアップロードメカニズムを介して、単に「半分」のものを配信することもできます。顧客は非常に偏執的であるため、エンドツーエンドの暗号化を維持することは非常に重要です。 頭に浮かぶ、それを完全に処理できるツールはありますか?1つの解決策は、専用ホスト上の顧客の敷地に完全なレジストリをミラーリングし、暗号化の部分をそのまま維持することです。 「標準」のソリューションは素晴らしいでしょう。何か無駄のない/軽量の/確立された/安定したものがすでにある場合、私は何かを一緒にハッキングするのは嫌です。 編集(+タイトルに編集):Portusによって提供されているような広範な許可スキームは良いスタートですが、実際の画像のエンドツーエンドの暗号化に理想的です。顧客は超偏執的で、Docker、クラウドベースのサービスなどを始めたばかりです。

2
JFrog ArtifactoryまたはJFrog Bintrayのどちらを使用するか?
私たちは実際にプロジェクトのパッケージ管理システムを探しています。ターゲットはシンプルで、パッケージ(アプリとミドルウェア)を保持し、CI / CDツール(Jenkins、Ansible、Docker ...)で使用するための集中システムを備えています。 JFrog ArtifactoryとJFrog Bintrayを発見したオプションを探しました。彼らは両方とも同じ仕事をしているように見えますが、JFrogが同じオプションで2つの並行製品を維持しているとは思いません。 ArtifactoryとBintrayの違いは何ですか? どのようにしてどちらを選ぶか、そしてその理由は?

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