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

12ファクターアドバイザリに準拠してサードパーティアプリケーションを展開していますが、ポイントの1つは、アプリケーションログをstdout / stderrに出力する必要があることを示しています。その後、クラスタリングソフトウェアがそれを収集できます。 ただし、アプリケーションはファイルまたはsyslogにのみ書き込むことができます。代わりにこれらのログを印刷するにはどうすればよいですか？

49 logging  cluster  docker  coreos 

ファイルがなくなったsystemdユニットを削除する方法がわかりません。彼らはまだ何らかの形でシステムに残っているようです。 私が削除しようとしている古い壊れたユニット： core@ip-172-16-32-83 ~ $ systemctl list-units --all firehose-router* UNIT LOAD ACTIVE SUB DESCRIPTION <E2><97><8F> firehose-router@02.service not-found failed failed firehose-router@02.service <E2><97><8F> firehose-router@03.service not-found failed failed firehose-router@03.service LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The …

40 systemd  coreos 

現在、サーバーとアプリの一部をcoreOS環境に移行することを考えています。ここで見た問題の1つは、コンテナーを新しいマシンに移動するときにcoreOSがDockerボリュームを処理しないため、永続データの管理です。いくつかの調査の後、glusterFSを見つけました。これは、すべての問題を解決できるクラスターファイルシステムであると主張しています。 私の現在のアイデアは次のとおり/mnt/glusterです。たとえば、各coreOSマシンで特権コンテナーとして実行され、ストレージを公開するglusterFSコンテナーがあります。私の中でDockerfileの私はすべてのボリュームがこのパスにマウントする必要があることを指定します。 次に検討したのは、どのコンテナが独自のボリュームを取得し、どのコンテナがボリュームを共有するかです。たとえば、すべてのmysqlコンテナは複製を自分で処理できるため、独自のボリュームを取得します。それをいじりたくありません。同じWebサイトにサービスを提供するWebサーバーは、「ユーザーがアップロードした画像」などのデータにデータを複製できないため、同じボリュームを適切に使用します。 誰かがこのようなことを試しましたか、私が見逃したものはありますか？

24 cluster  replication  docker  glusterfs  coreos 

CoreOS（835.9.0）の標準インストールがありますが、起動時にdockerデーモンが起動しません。SSHで起動してから起動するだけdocker psです。 システムの起動時にdockerデーモンを自動的に起動するにはどうすればよいですか？ ドッカーデーモンと言うと、ps -ef | grep dockerやるまでプロセスが表示されないdocker ps

23 boot  docker  coreos 

CoreOSを使用して、フリートでsystemdユニットをスケジュールしています。私は2つのユニットを持っている（firehose.serviceとfirehose-announce.service私が取得しようとしています。firehose-announce.service一緒に起動・停止するfirehose.service。ここのユニットファイルです。firehose-announce.service： [Unit] Description=Firehose etcd announcer BindsTo=firehose@%i.service After=firehose@%i.service Requires=firehose@%i.service [Service] EnvironmentFile=/etc/environment TimeoutStartSec=30s ExecStartPre=/bin/sh -c 'sleep 1' ExecStart=/bin/sh -c "port=$(docker inspect -f '{{range $i, $e := .NetworkSettings.Ports }}{{$p := index $e 0}}{{$p.HostPort}}{{end}}' firehose-%i); echo -n \"Adding socket $COREOS_PRIVATE_IPV4:$port/tcp to /firehose/upstream/firehose-%i\"; while netstat -lnt | grep :$port >/dev/null; do etcdctl set /firehose/upstream/firehose-%i $COREOS_PRIVATE_IPV4:$port …

20 systemd  coreos 

Webサーバー（Apache 2など）を備えたDockerコンテナーがあるとします。次に、その下のOSを更新します。このSFの答えは、最良の方法はベースイメージと私のApacheイメージを再構築することだと言います。ただし、新しいコンテナを作成する前に古いコンテナを削除する必要があるため、イメージをデプロイするとダウンタイムが発生します。したがって、ポート80/443にバインドするコンテナは1つだけです。 しかし、ダウンタイムなしでこの更新プログラムを展開するにはどうすればよいですか？ロードバランサーを使用し、コンテナー間通信を使用する必要がありますか？また、ロードバランサーを更新するにはどうすればよいですか？

17 docker  uptime  coreos 

今日はあなたのために謎があります。AzureでCoreOS（2023.5.0 / Linux 4.19.25-coreos）に基づいた小さな3ノードのElasticsearchクラスターを実行します。Elasticsearchは、ホストネットワークモードのDockerコンテナ内で実行されます。ほぼ完全にメンテナンスフリーで1年以上稼働した後、マシンが非常に興味深い状態になるのを見てきました。 更新 この問題は、Linuxカーネルのドライバーを修正することで解決しました。以下の回答をご覧ください。 症状 基本的に、影響を受けるマシンと他の2つのノード間のネットワークは停止します。すべてが同じ仮想ネットワークと同じサブネットにあり、通常は他のeathと通信できます。影響を受けるノードは、他のサブネット（sshに接続できます）および別のピア仮想ネットワークからも到達できます。マシンにはインターネットへの（非常にむらのある）接続もありますが、ほとんどの要求はタイムアウトになります。 影響を受けるノードで報告される「使用されるソケット」の数/proc/net/sockstatが非常に多いことを確認しました（正常なノードでは〜300ではなく〜4.5k）。監視により、この数はノードが利用できなくなった瞬間から急速に増加することがわかります。 面白いのは、これらの使用済みソケットのソースを特定できないように見えることです。 # cat /proc/net/sockstat sockets: used 4566 TCP: inuse 2 orphan 0 tw 2 alloc 98 mem 4 UDP: inuse 1 mem 0 UDPLITE: inuse 0 RAW: inuse 0 FRAG: inuse 0 memory 0 # cat /proc/net/sockstat6 TCP6: inuse 98 UDP6: …

14 linux-networking  linux-kernel  tcpdump  coreos  azure-networking 

現在、新しいApache Mesosクラウドセットアップのアーキテクチャを設計しています。目標は、異なるスタックを同じアーキテクチャに移動することでシステムを統合することです。主なワークロードは、Apache Sparkを使用したビッグデータ分析と、Webサーバー、メールサーバーなどの企業インフラストラクチャです。 アイデアは、Mesos（Marathon / Chronos、AuroraまたはSingularity）で使用可能なスケジューラーの1つで実行されているDockerコンテナーでWebサービスを実行することです。したがって、これは最初のMesosフレームワークグループになります。その隣に、Apache Sparkフレームワークとデータストレージ用のいくつかのデータベースフレームワークがあります。これはMesosフレームワークの2番目のグループになります。テストのためにすべてを並行して実行した後、詳細を選択します。 ただし、Mesos自体を実行する基準を決定するのは困難です。理想的には、できる限り金属の近くで実行する必要があります。また、オーケストレーションソリューションを使用して、Mesosおよびフレームワークデーモンが常に障害時に実行/再起動されるようにします。検討しているオプションは次のとおりです。 1）Mesosとフレームワークを最小限のOSでDockerコンテナーとして実行する。この点で、私たちは現在、CoreOSとFleetに傾いています。 2）Ubuntu / DebianサーバーでMesosとフレームワークを直接実行します。このオプションでは、フォアマンとパペットに傾いています。 質問については、重要な順に、次の解決策を特定しようとしています。 構成するのが最も簡単です 維持および更新を維持するのが最も簡単です オーバーヘッドが最も少ない これまでにCoreOSを使用したことはありませんが、私たちが向かっているように見えるオプションです。私がこれに関して抱えている大きな（主観的な）問題の1つは、DockerコンテナーでMesosを実行してから、MesosでDockerコンテナーを実行することです。これは「不潔」で間違っているようです。これはメリットのない考慮事項ですか？ 同様の考え方は、レイヤー間の冗長性にも関係しています。私がどこから来たのかを説明するために、Mesosが金属の上で実行される実際のOSであるなら、私は好むでしょう。使用する基盤に関係なく、アーキテクチャの複数の層（つまり、CoreOS＆Fleet＆SystemD == Mesos＆Marathon＆Chronos）で同じ意図された機能が得られるようです。これは避けられませんか？ 基準を考慮して、検討に失敗したMesosの下のレイヤーを実行する他の良いオプションはありますか？

9 puppet  cloud  coreos  foreman  apache-mesos 

CoreOSで実行しているサーバーインスタンスの検出サイドキックサービス用のかなり単純なユニットファイルがあります。ユニットファイルは次のようになります。 [Unit] Description=Discovery for frontend server (instance %i) BindsTo=frontend@%i.service After=frontend@%i.service [Service] EnvironmentFile=/etc/environment ExecStart=/usr/bin/bash -c ' \ while true; do \ export PORT=$(docker port frontend%i 80 | sed s/.*://); \ etcdctl set /services/frontend/%i "${COREOS_PRIVATE_IPV4}:$PORT" --ttl 60; \ sleep 45; \ done' ExecStop=/usr/bin/etcdctl rm /services/frontend/%i [X-Fleet] MachineOf=frontend@%i.service これは問題なく動作しますが、この段階に到達するには年齢がかかりました。etcdctl行を次のように変更すると、 etcdctl set /services/frontend/%i "${COREOS_PRIVATE_IPV4}:${PORT}" …

9 bash  systemd  coreos