คำถามติดแท็ก coreos

ฉันกำลังปรับใช้แอปพลิเคชันของบุคคลที่สามให้สอดคล้องกับคำแนะนำ 12 ปัจจัยและอย่างใดอย่างหนึ่งที่บอกว่าควรพิมพ์แอปพลิเคชันบันทึกไปยัง stdout / stderr: จากนั้นซอฟต์แวร์การจัดกลุ่มสามารถรวบรวมได้ อย่างไรก็ตามแอปพลิเคชันสามารถเขียนไปยังไฟล์หรือ syslog เท่านั้น ฉันจะพิมพ์บันทึกเหล่านี้ได้อย่างไร

49 logging  cluster  docker  coreos 

ฉันมีปัญหาในการหาวิธีลบ systemd units ที่ไม่มีไฟล์อีกต่อไป พวกเขาดูเหมือนจะยังคงอยู่ในระบบอย่างใด หน่วยที่ชำรุดเก่าที่ฉันพยายามลบ: 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 …

40 systemd  coreos 

ขณะนี้ฉันกำลังคิดเกี่ยวกับการย้ายเซิร์ฟเวอร์และแอพของเราไปยังสภาพแวดล้อมcoreOS หนึ่งในปัญหาที่ฉันเห็นที่นี่คือการจัดการข้อมูลถาวรเนื่องจาก coreOS ไม่ได้จัดการกับโวลุ่มที่มีปริมาณ Docker เมื่อย้ายคอนเทนเนอร์ไปยังเครื่องใหม่ หลังจากการวิจัยบางอย่างฉันพบglusterFSซึ่งอ้างว่าเป็นระบบไฟล์คลัสเตอร์ที่สามารถแก้ปัญหาทั้งหมดของฉัน แนวคิดปัจจุบันของฉันคือ: ฉันมีคอนเทนเนอร์ glusterFS ซึ่งทำงานเป็นคอนเทนเนอร์ที่มีสิทธิพิเศษบนเครื่อง coreOS แต่ละเครื่องของฉันและแสดงที่เก็บข้อมูล/mnt/glusterตัวอย่างเช่น ในของDockerfileฉันฉันระบุว่าปริมาณทั้งหมดของฉันควรจะติดตั้งบนเส้นทางนี้ สิ่งต่อไปที่ฉันพิจารณาคือคอนเทนเนอร์ที่ควรรับวอลุ่มของตนเองและที่ควรแบ่งใช้ ตัวอย่างเช่นทุกmysqlคอนเทนเนอร์จะได้รับวอลลุ่มของมันเองเพราะมันสามารถจัดการกับการเรพลิเคทด้วยตัวมันเอง ฉันไม่ต้องการยุ่งกับสิ่งนั้น Webservers ที่ให้บริการเว็บไซต์เดียวกันจะใช้วอลลุ่มเดียวกันสำหรับสิ่งต่างๆเช่น "รูปภาพที่ผู้ใช้อัปโหลด" เป็นต้นเนื่องจากพวกเขาไม่สามารถจำลองข้อมูลเหล่านั้นได้ มีใครลองอะไรแบบนี้หรือมีอะไรที่ฉันพลาดไปบ้างไหม?

24 cluster  replication  docker  glusterfs  coreos 

ฉันมีการติดตั้งวานิลลาของ CoreOS (835.9.0) และมันไม่ได้เริ่มต้น docker daemon เมื่อเริ่มต้น มันเริ่มต้นเมื่อฉัน SSH docker psและทำเช่น ฉันจะทำให้ docker daemon เริ่มทำงานโดยอัตโนมัติเมื่อบูตระบบได้อย่างไร เมื่อฉันพูดนักเทียบท่าภูตฉันหมายถึงps -ef | grep dockerไม่แสดงกระบวนการจนกว่าฉันจะทำdocker ps

23 boot  docker  coreos 

ฉันใช้ CoreOS เพื่อจัดตาราง systemd units กับกองยาน ฉันมีสองหน่วย ( 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 …

20 systemd  coreos 

สมมติว่าฉันมีที่เก็บ Docker พร้อมเว็บเซิร์ฟเวอร์ (เช่น Apache 2) ตอนนี้ฉันต้องการอัปเดตระบบปฏิบัติการภายใต้ คำตอบ SF นี้บอกว่าวิธีที่ดีที่สุดคือการสร้างอิมเมจพื้นฐานและอิมเมจ Apache ของฉันใหม่ แต่การปรับใช้อิมเมจนั้นหมายถึงการหยุดทำงานเนื่องจากฉันต้องลบคอนเทนเนอร์เก่าก่อนที่จะสร้างใหม่ดังนั้นจึงมีคอนเทนเนอร์เดียวเท่านั้นที่เชื่อมกับพอร์ต 80/443 แต่ฉันจะปรับใช้การอัปเดตนี้ด้วยการหยุดทำงานเป็นศูนย์ได้อย่างไร ฉันควรใช้ตัวโหลดบาลานซ์และใช้การสื่อสารระหว่างคอนเทนเนอร์หรือไม่? และฉันจะอัพเดตตัวโหลดบาลานซ์ได้อย่างไร?

17 docker  uptime  coreos 

วันนี้ฉันมีเรื่องลึกลับสำหรับคุณ เราเรียกใช้คลัสเตอร์ Elasticsearch ขนาดเล็กสามโหนดที่ใช้ CoreOS (2023.5.0 / Linux 4.19.25-coreos) บน Azure Elasticsearch ทำงานภายในคอนเทนเนอร์นักเทียบท่าในโหมดโฮสต์เครือข่าย หลังจากใช้งานการบำรุงรักษาเกือบทั้งหมดฟรีเป็นเวลานานกว่าหนึ่งปีเราได้เห็นเครื่องเข้าสู่สถานะที่น่าสนใจมาก ปรับปรุง ปัญหานี้ถูกแก้ไขได้โดยการแก้ไขที่จะขับรถในลินุกซ์เคอร์เนล ดูคำตอบด้านล่าง อาการ โดยพื้นฐานแล้วการเชื่อมต่อระหว่างเครื่องที่ได้รับผลกระทบและอีกสองโหนดจะตาย ทั้งหมดอยู่ในเครือข่ายเสมือนเดียวกันและเครือข่ายย่อยเดียวกันและสามารถสื่อสารกับ eath อื่น ๆ ได้ โหนดที่ได้รับผลกระทบยังสามารถเข้าถึงได้จากเครือข่ายย่อยอื่น ๆ (ฉันสามารถ ssh เข้าไปได้) และจากเครือข่ายเสมือนที่แตกต่างกัน เครื่องยังมีการเชื่อมต่อกับอินเทอร์เน็ต (ขาด ๆ หาย ๆ ) แต่การร้องขอส่วนใหญ่จะหมดเวลา เราสังเกตว่าบนโหนดที่ได้รับผลกระทบจำนวน "ซ็อกเก็ตที่ใช้" ที่รายงานโดย/proc/net/sockstatมีค่าสูงมาก (~ 4.5k แทน ~ 300 บนโหนดที่มีสุขภาพดี) การตรวจสอบแสดงให้เห็นว่าจำนวนนี้เพิ่มขึ้นอย่างรวดเร็วจากช่วงเวลาที่โหนดจะไม่พร้อมใช้งาน สิ่งที่สนุกคือเราไม่สามารถระบุแหล่งที่มาของซ็อกเก็ตที่ใช้แล้ว: # cat …

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

ขณะนี้เรากำลังอยู่ในขั้นตอนของการออกแบบสถาปัตยกรรมของ Apache Mesos ระบบคลาวด์ใหม่ของเรา เป้าหมายคือการรวมระบบของเราด้วยการย้ายสแต็คที่แตกต่างกันไปยังสถาปัตยกรรมเดียวกัน ภาระงานหลักคือการวิเคราะห์ข้อมูลขนาดใหญ่โดยใช้ Apache Spark และโครงสร้างพื้นฐานขององค์กรของเรารวมถึงเว็บเซิร์ฟเวอร์เซิร์ฟเวอร์อีเมล ฯลฯ แนวคิดคือการเรียกใช้บริการเว็บของเราในคอนเทนเนอร์ Docker ที่ทำงานบนหนึ่งในตัวกำหนดเวลาที่ใช้ได้สำหรับ Mesos (Marathon / Chronos, Aurora หรือ Singularity) นี่จะเป็นกลุ่มกรอบ Mesos แรก ถัดจากนั้นเราจะมี Apache Spark framework และเฟรมเวิร์กฐานข้อมูลต่าง ๆ สำหรับการจัดเก็บข้อมูล นี่จะเป็นเฟรมเวิร์กของ Mesos กลุ่มที่สอง เราจะเลือกเฉพาะหลังจากเรียกใช้พวกเขาทั้งหมดในแบบคู่ขนานสำหรับการทดสอบ อย่างไรก็ตามเรามีปัญหาในการตัดสินใจซึ่งพื้นฐานในการเรียกใช้ Mesos เอง เป็นการดีที่เราต้องการเรียกใช้มันให้ใกล้เคียงกับโลหะมากที่สุด นอกจากนี้เรายังต้องการใช้วิธีการแก้ปัญหาแบบออเคสตร้าเพื่อให้แน่ใจว่า Mesos & framework daemons นั้นทำงาน / รีสตาร์ทเมื่อล้มเหลวเสมอ ตัวเลือกที่เรากำลังพิจารณามีดังนี้: 1) การเรียกใช้ Mesos …

9 puppet  cloud  coreos  foreman  apache-mesos