タグ付けされた質問 「databases」

私はDockerのユースケースについて友人と議論しています。チームの1人の男は、あらゆる種類のDockerを使用したいと考えています-ユニバーサルUNIXプロセスラッパーのようなもの。もう1人は、DockerはマイクロサービスやAWS Lambdaスタイルのアプリなどのステートレスアプリケーションにのみ使用すべきだと考えています。 両方の概念実証を設計しました。Dockerクラスターには、Dockerホストのマウント時にマウントされる共有ドライブがあり、コンテナー内のデータベースがマウントされている場合は、単に共有ドライブにボリュームをマウントします。 私の友人は、相反する証拠を見せられたにもかかわらず、彼の立場に固執しています。（彼はまた、Dockerがスタックに複雑さを追加することで不必要なリスクを追加すると主張しています。） 私は彼の視点を聞いて理解しようとしています。共感の行為だけでなく、彼とのより良い理由にも。（私たちは皆、非常にうまくやっています-それで、これはインジェストと真剣な議論の混合です）。 質問の背後にある質問の種類は次のとおりです。データベースは牛ですか？このコメントは、データベースの適切な自動化されたバックアップおよび取得戦略が、牛サーバーと見分けがつかないことを示唆しています。 私の質問は、Dockerをデータベースに使用すべきでない理由は何ですか？ 編集： 人々は私の用語を明確にするように私に頼みました。データベースアプリケーションはコンテナにあり、ストレージはボリュームにあると想定していました。つまり、RDBMSはコンテナ内にあり、データベースストレージはボリューム内にあります。 一部のコメンテーターは、ドッカーボリュームドライバーがデータベースの書き込みでうまく機能しないことを示唆しています。（またはその効果をもたらすもの）。それについて詳しく説明していただけますか？

25 containers  databases  cattle-vs-pet  risk 

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

17 continuous-delivery  continuous-deployment  databases 

これは、環境変数/構造に関するメソッドとアドバイスに関する非常に幅広い質問です。しかし、最終的には「環境変数をどのように保存すればよいですか？」という非常に具体的な質問に対する答えを探しています。 まず、いくつかの説明： 私にとっての環境は3〜10台のサーバーであり、特定の顧客のインフラストラクチャを含める方法です。 各環境内にはいくつかの変数があり、それらはほとんどいくつかのキー入力（名前、サイズなど）から自動的に生成されます。 現状では、すべての環境変数を次のような構造に格納しています。 <playbook>.yml # Various playbooks for deployment roles/windows # Ansible role for Ubuntu roles/ubuntu # Ansible role for Ubuntu config/hosts/<name>.yml # Ansible inventory config/hosts/vars/<name>.json # Environment specific variables 現在、構成は上記のgitリポジトリのサブモジュールとして初期化されています。変数ファイルはかなり頻繁に変更されるため、これによりデータの変更に関する問題が発生し、コミット間で1回、2回、または3回でさえ、変更の追跡がますます困難になります。 個人的にはこれから先を見ますが、すべての顧客変数を一元化された/スケーラブルな方法で保存し、次にansibleを使用して動的なインベントリでそれに接続する必要があります。 Consulのように、必要とされる可能性のある部分を実行しているように見えるいくつかのテクノロジーがあることは理解していますが、それらは、小さなわずかに異なる多数のアプリケーションではなく、1つの大きなアプリケーションを提供する環境で最適に動作するようです。 基本的には、インベントリスクリプトを作成し、すべてのデータを目的外に構築されたデータベースに移動し、何も変更されていないかのように続行する必要があることを理解しています。これはおそらく、現在保存している多くのデータを潜在的に削減する方法であると考えています。おそらく、単にデータを再利用するだけでなく、データを保存するさまざまな方法を検討しています。 1つ、2つ、または3つの巨大な環境ではなく、多くの小規模な環境に対処する必要がある場合、誰かがコードとしてインフラストラクチャを実装した経験があることを願っています。 助言がありますか？

11 ansible  configuration  databases  provisioning  environment-variables 

ステートレスアプリの定義は、 MongoDBやMySQLなどのデータベースサーバーに適用されるようです。Helm Chartsは、Kubernetesのテンプレートリポジトリの一種として見つかりました。ただし、安定ビルドはすべてのデプロイメントを使用します。安定した状態で提供されないインキュベーター内のみ。 DBサーバーにDeploymentを使用するとどのような影響がありますか？ たとえば、クラスターで複数のインスタンスを実行しているときに、同期/レプリケーションの問題などの問題はありますか？ 背景：フェイルオーバークラスターでMongoDBを実行したいので、少なくとも2つのインスタンスが実行されています。

7 kubernetes  databases  helm 

この質問にはすでに回答があります： データベースの継続的な展開を可能にするプラクティスまたはツールは何ですか？ （6つの答え） 5か月前に閉鎖。 私はDevOpsエンジニアであり、数か月前のチームのソフトウェアエンジニアです。開発者は、中央のOracle DBから、個々のラップトップのCentOS VMにDBを持つことに移行しました。中央DBからの移行は、DBAへの依存を減らし、データの不整合に起因する問題を排除することでした。 チームの全員とデータベースの共有と同期を確実にする計画は、各人が全員と変更スクリプトを共有することでした。問題は、Skypeを使用して通信を行うことです（スラックをセットアップするだけですが、まだ完全には使い始めていません）。DB変更スクリプトのテキストが投稿されることもありますが、見落とされる場合があります。もう1つの問題は、一部の開発者が変更の投稿を見逃していることです。さらに、新しいリリースは本番環境にデプロイされ、テストおよびデモ環境にはデプロイされません。 これは私たち、特に最近の私にとって深刻な課題となっており、デモの展開とプロダクションの展開を確実に同期させる責任がありました。同期に関する問題のほとんどは、変更スクリプトがないか、DBオブジェクトがないために、データベースが同期されていないことにあります。Oracleは私たちの好みのDBです。 デモ環境での一般的な展開は、アプリケーションのテストを含む非常に痛みを伴うプロセスであり、DBテーブルの列、関数、ストアドプロシージャの欠落が原因で問題が発生するため、欠落しているDBオブジェクトを探し、それらをDBに適用してから、すべての問題が解決されるまで続行します。 この問題を解決して、スムーズで痛みのない、時間のかからない展開を確実にするにはどうすればよいですか？アプリケーションをDockerに移行すると、DB同期の問題と、それに伴う開発者の規律の欠如を解決できますか？この分野で改善するためにどのようなプロセスを導入できるでしょうか？

7 deployment  continuous-delivery  databases  environments