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

เมื่อปรับใช้แอปพลิเคชันไปยังเซิร์ฟเวอร์โดยทั่วไปจะมีการแยกระหว่างสิ่งที่แอปพลิเคชันรวมกับตัวเองและสิ่งที่คาดหวังจากแพลตฟอร์ม (ระบบปฏิบัติการและแพ็คเกจที่ติดตั้ง) ประเด็นหนึ่งคือการที่แพลตฟอร์มสามารถอัปเดตได้โดยอิสระจากแอปพลิเคชัน สิ่งนี้มีประโยชน์เช่นเมื่อจำเป็นต้องใช้การอัปเดตความปลอดภัยอย่างเร่งด่วนกับแพ็คเกจที่จัดทำโดยแพลตฟอร์มโดยไม่ต้องสร้างแอปพลิเคชันใหม่ทั้งหมด การอัปเดตความปลอดภัยแบบดั้งเดิมนั้นถูกนำไปใช้โดยเพียงแค่ดำเนินการคำสั่ง package manager เพื่อติดตั้งแพ็กเกจเวอร์ชันที่อัพเดตบนระบบปฏิบัติการ (เช่น "yum update" บน RHEL) แต่ด้วยการถือกำเนิดของเทคโนโลยี container เช่น Docker ที่รูปของ container รวมทั้งแอพพลิเคชั่นและแพลตฟอร์มเป็นวิธีที่ยอมรับได้ในการรักษาระบบด้วย container เป็นอะไร? ทั้งโฮสต์และคอนเทนเนอร์มีชุดแพ็กเกจของตนเองที่เป็นอิสระที่จำเป็นต้องอัพเดตและอัพเดตบนโฮสต์จะไม่อัพเดตแพ็กเกจใด ๆ ภายในคอนเทนเนอร์ ด้วยการเปิดตัว RHEL 7 ที่มีคุณสมบัติพิเศษของ Docker container มันน่าสนใจที่จะได้ยินว่า Redhat แนะนำวิธีใดในการจัดการกับการอัปเดตความปลอดภัยของคอนเทนเนอร์ ความคิดเกี่ยวกับตัวเลือกบางอย่าง: การปล่อยให้แพ็กเกจอัพเดตตัวจัดการแพ็กเกจบนโฮสต์จะไม่อัพเดตแพ็กเกจภายในคอนเทนเนอร์ ต้องสร้างภาพคอนเทนเนอร์ทั้งหมดเพื่อใช้การอัปเดตดูเหมือนว่าจะแยกความแตกต่างระหว่างแอปพลิเคชันและแพลตฟอร์ม (การอัปเดตแพลตฟอร์มต้องเข้าถึงกระบวนการสร้างแอปพลิเคชันซึ่งสร้างอิมเมจ Docker) การรันคำสั่งแบบแมนนวลภายในแต่ละคอนเทนเนอร์ที่รันอยู่นั้นดูเหมือนว่ายุ่งยากและการเปลี่ยนแปลงมีความเสี่ยงที่จะถูกเขียนทับในครั้งต่อไปที่คอนเทนเนอร์ถูกอัพเดตจากแอ็พพลิเคชันการปล่อยสิ่งประดิษฐ์ ดังนั้นวิธีการเหล่านี้จึงไม่น่าพอใจ

117 linux  security  redhat  docker  containers 

วิธีใดที่แนะนำให้ใช้สำหรับการอัปเดตคอนเทนเนอร์ของบริการที่ทำงานใน Amazon ECS เอกสาร AWSกล่าวว่า: "ถ้าคุณมีการปรับปรุงภาพหางของแอพลิเคชันของคุณคุณสามารถสร้างคำนิยามของงานใหม่ที่มีภาพที่และปรับใช้ในการให้บริการของคุณหนึ่งงานในเวลา." นี่คือทุกสิ่งที่มีอยู่ในเอกสารปัจจุบัน (13 เมษายน 2558) ฉันเข้าใจถูกต้องหรือไม่ว่าทางเดียวที่จะอัปเดตแอปพลิเคชันคอนเทนเนอร์ของฉันใน Amazon ECS คือการสร้างงานใหม่จากนั้นหยุดงานเก่าและเริ่มงานใหม่ ฉันใช้แท็ก "ล่าสุด" สำเร็จแล้วด้วย Core OS & Fleetctl สิ่งนี้มีประโยชน์ที่ไม่จำเป็นต้องเปลี่ยนแท็กรูปภาพของนักเทียบท่าสำหรับการอัปเดตใหม่เนื่องจากการโหลดบริการใหม่จะเห็นการเปลี่ยนแปลงใหม่และอัปเดตคอนเทนเนอร์ (ใช้แท็กเดียวกัน "ล่าสุด") คุณใช้วิธีใดในการอัปเดตบริการของคุณด้วยอิมเมจ Docker ที่อัปเดตใน Amazon ECS

32 amazon-web-services  update  docker  containers  amazon-ecs 

การdocker-compose runอ้างอิงระบุว่ามี--rmตัวเลือกให้ ลบคอนเทนเนอร์หลังจากรัน ฉันต้องการให้เริ่มต้นนี้พฤติกรรมสำหรับบริการบางอย่างของฉันระบุในrundocker-compose.yml ดังนั้นคำถามคือ : จะสามารถระบุได้docker-compose.ymlไหม? ถ้าทำได้ฉันจะทำอย่างไร ( INB4 "ใช้นามแฝงทุบตีลุค!" : แน่นอนว่าฉันสามารถบังคับใช้สิ่งนี้ได้docker-compose.ymlโดยการตั้งค่านามแฝงทุบตีบางอย่างเช่นalias docker-compose-run='docker-compose run --rm'แต่ฉันสนใจว่าฉันจะบังคับใช้สิ่งนั้นผ่านอย่างแน่นอนdocker-compose.ymlได้อย่างไรไม่ได้อยู่นอกขอบเขต)

24 docker  containers 

ฉันกำลังพยายามเพิ่มไฟล์ลงในภาพ Docker ที่สร้างขึ้นจากtomcatภาพอย่างเป็นทางการ ภาพนั้นดูเหมือนว่าจะไม่มีสิทธิ์ในการใช้รูทเนื่องจากฉันลงชื่อเข้าใช้ในฐานะผู้ใช้tomcatถ้าฉันใช้ bash: docker run -it tomcat /bin/bash tomcat@06359f7cc4db:/usr/local/tomcat$ ถ้าผมสั่งDockerfileการคัดลอกไฟล์ไปยังภาชนะที่ไฟล์มีสิทธิ์และเป็นเจ้าของ644 rootเท่าที่ฉันเข้าใจดูเหมือนว่าจะสมเหตุสมผลเนื่องจากคำสั่งทั้งหมดใน Dockerfile นั้นทำงานเหมือนรูท อย่างไรก็ตามหากฉันพยายามเปลี่ยนความเป็นเจ้าของไฟล์tomcat:tomcatนั้นเป็นฉันได้รับOperation not permittedข้อผิดพลาด ทำไมฉันไม่สามารถเปลี่ยนการอนุญาตของไฟล์ที่คัดลอกไปยังรูปภาพนั้นได้? สามารถทำซ้ำได้อย่างไร: mkdir docker-addfilepermission cd docker-addfilepermission touch test.txt echo 'FROM tomcat COPY test.txt /usr/local/tomcat/webapps/ RUN chown tomcat:tomcat /usr/local/tomcat/webapps/test.txt' > Dockerfile docker build . ผลลัพธ์ของdocker build .: Sending build context to Docker daemon …

16 file-permissions  docker  containers 

ฉันกำลังพยายามใช้อุปกรณ์วนรอบภายในคอนเทนเนอร์เพื่อเมานต์ไฟล์ภาพบางส่วน: > sudo losetup /dev/loop0 test.img losetup: /dev/loop0: failed to set up loop device: No such file or directory /dev/loop0 ไม่มีอยู่จริงและ > sudo mknod /dev/loop0 b 7 0 mknod: ‘/dev/loop0’: Operation not permitted ฉันจะทำงานนี้ได้อย่างไร คอนเทนเนอร์ต้องการสิทธิ์ cgroup ที่อาจไม่มีหรือไม่

14 linux  containers  cgroup  loop-device 

ฉันเรียกใช้คอนเทนเนอร์นักเทียบเคียงกับหัวหน้างานเช่นนี้: Dockerfile CMD ["/run.sh"] run.sh #!/usr/bin/env bash exec supervisord -n ผู้บังคับบัญชา serf.conf [group:job] programs=serf,producer [program:serf] command=/start-serf-agent.sh numprocs=1 autostart=true autorestart=unexpected stopasgroup=true killasgroup=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0 start-serf-agent.sh #!/bin/bash exec serf agent --join=serf:7946 -tag role=producer ผู้บังคับบัญชา servce.conf [program:producer] command=/start.sh numprocs=1 stopasgroup=true killasgroup=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0 start.sh #!/bin/bash exec /producer --project=${NAME} หลังจากที่ผู้ผลิตหยุดฉันก็มี: …

14 linux  docker  process  supervisord  containers 

มันเป็นเรื่องยากหากพยายามอยู่ในช่วงที่ดีของ Red Hat และยังคงวางแผนการใช้งานของระบบที่ยืนยาว ... ฉันเป็นผู้สนับสนุนของLinux Containers (LXC)มานานกว่าหนึ่งปี การติดตั้งเริ่มต้นของฉันอยู่บนพื้นฐานของข้อมูลที่รวบรวมได้จากบทเรียนออนไลน์เช่นนี้และหนึ่งในนี้ นี้แน่นิ่งlxc-create, lxc-start|stopและlxc-destroyคำสั่งที่มีอยู่และการปรับเปลี่ยนแม่แบบ OpenVZ สิ่งนี้ใช้ได้ดีและทำงานอย่างมีความสุขในการผลิต อย่างไรก็ตามฉันกำลังนำระบบเพิ่มเติมมาใช้และตัดสินใจที่จะตรวจสอบเอกสารปัจจุบันของ Red Hat เกี่ยวกับคอนเทนเนอร์ใน EL6 ฉันรู้สึกประหลาดใจที่ได้เห็นจุดยืนอย่างเป็นทางการของพวกเขาในเรื่องนี้ ในไม่ RHEL 6 ให้เครื่องมือ LXC จำเป็นในการใช้ลินุกซ์คอนเทนเนอร์? , Red Hat อธิบาย LXC เป็นดูตัวอย่างเทคโนโลยีและแนะนำให้ใช้ libvirt ในการจัดการสร้างและจัดการตู้คอนเทนเนอร์ แต่ทว่าออราเคิลยังสนับสนุนเทคนิคการจัดตู้คอนเทนเนอร์ที่แตกต่างกันโดยสิ้นเชิงใน Unbreakable Linux ดูเหมือนจะมีฟังก์ชั่นที่ขาดหายไปในวิธีการ libvirt แต่วิธีการเริ่มต้นของฉันกับคำสั่ง lxc- * เป็นกระบวนการแบบแมนนวล ... ฉันไม่สามารถบอกได้เลยว่าอะไรถูกหรือวิธีการ "ยอมรับ" ในการจัดการคอนเทนเนอร์บน EL6 . อะไรคือภูมิปัญญาดั้งเดิมเกี่ยวกับระบบ LXC …

13 centos  redhat  libvirt  lxc  containers 

ให้บอกว่าเรามีเซิร์ฟเวอร์เป็นหนึ่งเดียวกับ LXC ติดตั้งและภาชนะ LXC ที่ใช้สำหรับเป็นฐาน /var/lib/lxc/ubuntu_baseimg เพื่อความง่ายให้ลืมการเปลี่ยนแปลงการตั้งค่าหลังจากคัดลอก img img บางคนแนะนำให้ใช้ subvolumes และ snapshots สำหรับการสร้างตู้คอนเทนเนอร์ใหม่ แต่ใคร ๆ ก็สามารถทำ cp --reflink กับผลลัพธ์ที่คล้ายกันได้อย่างง่ายดาย แล้ววิธีการของโพรปเปอร์คืออะไร (หรือดีกว่า) สำหรับการจัดการหลาย ๆ คอนเทนเนอร์? ภาพรวม วิธีนี้ดูดีที่สุด แต่คำสั่งเช่น lxc-destroy จะไม่ทำงานเนื่องจากจะไม่สามารถลบไดเรกทอรีได้ btrfs subvolume snapshot /var/lib/lxc/ubuntu_base /var/lib/lxc/container_1 cp พร้อม reflink ฉันไม่แน่ใจว่ามีความแตกต่างด้านประสิทธิภาพหรือไม่ระหว่างสแนปชอตนี้ cp --reflink=always /var/lib/lxc/ubuntu_base /var/lib/lxc/container_1 หรือมีวิธีการอื่นที่ดีกว่าในการทำสิ่งนี้ซึ่งฉันไม่ทราบ แก้ไข: สิ่งหนึ่งที่ฉันเห็นด้วยตัวเลือก reflink คือคุณไม่สามารถลบที่เก็บฐานถ้าคนอื่นกำลังทำงานเพราะ/procและ/devมีการติดตั้งและไม่เคยเปลี่ยนการอ้างอิงเสมอเหมือนกัน แต่การปิดตู้คอนเทนเนอร์ที่มีดอกป๊อบทั้งหมดดูเหมือนจะช่วยได้

11 snapshot  lxc  btrfs  containers 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นไปตามหัวข้อสำหรับข้อบกพร่องของเซิร์ฟเวอร์ ปิดให้บริการใน6 ปีที่ผ่านมา LXC คืออะไร มีประโยชน์อย่างไร? ความแตกต่างระหว่าง LXC และการจำลองเสมือนทั่วไปคืออะไร

9 linux  lxc  containers 

ฉันไม่LXCผู้เชี่ยวชาญ แต่เท่าที่ผมรู้ว่ามันเป็นจริงคล้ายกับลินุกซ์ vserver หากถูกต้องฉันสงสัยว่าทำไมมีผู้เล่นอื่นในค่ายเสมือนจริงที่แออัดไปแล้ว? LXC ให้อะไร (หรือสัญญา) ที่ linux-vserver ไม่มี? ฉันเป็นผู้ใช้ linux-vserver เป็นเวลานานฉันจำได้ว่ามันเป็นเวลาหลายปีก่อนหน้าการทำเวอร์ชวลไลเซชันทั้งหมด การพัฒนาช้าลงในช่วงไม่นานมานี้ แต่ไม่เคยหยุดเลย - ฉันรู้เพราะนักพัฒนาช่วยให้ฉันนำมันกลับไปสู่สถานะที่มีประโยชน์บน linux / hppa (ใน Gentoo อย่างน้อย) พวกเขาผลักดันแพทช์กับเมล็ดล่าสุดอย่างสม่ำเสมอโดยใช้สารพัดล่าสุด (โครงสร้างพื้นฐานของตู้คอนเทนเนอร์เดียวกันกับที่ใช้โดย LXC) และรวมเข้ากับ GRsecurity คนที่เริ่มความพยายามของ LXC อาจมีเหตุผลที่ดีที่จะทำเช่นนั้นแทนที่จะเข้าร่วมฐาน linux-vserver ที่จัดตั้งขึ้นแล้ว ถ้าอย่างนั้นฉันก็อยากจะรู้ มันคือทั้งหมดที่เกี่ยวกับการรวมฉีด? ถ้าอย่างนั้นทำไมไม่ปรับใช้ linux-vserver สำหรับการรวมระบบเหมือนที่คน Xen กำลังทำกับ XenLinux

9 linux  virtualization  containers  lxc  linux-vserver