CoreOS에서 부팅시 Docker 데몬이 시작되지 않음


23

CoreOS (835.9.0)의 바닐라 설치가 있으며 시작할 때 도커 데몬을 시작하지 않습니다. 내가 SSH 할 때만 시작하고 예를 들어 docker ps.

시스템 부팅시 도커 데몬이 자동으로 시작되도록하려면 어떻게해야합니까?

도커 데몬이라고 말하면, 내가 ps -ef | grep docker할 때까지 프로세스가 없음을 의미합니다.docker ps

답변:


40

sudo systemctl enable docker 트릭을했다.


2
고마워요 .Docker 문서를 읽었고 도움이되는 것을 찾을 수 없었습니다. 다시 시작 정책에 대해 많이 찾았지만 물론 Docker 데몬이 시작된 후에 만 ​​적용됩니다.
Chris

6
배경 : 이것의 근원은도 커가 CoreOS에서 소켓 활성화되어 있기 때문입니다. 즉, 부팅 체인을 차단하지 않습니다. 디스크에 컨테이너가 많을 때 도커의 초기 버전이 느리게 시작되어 도커에 의존하는 모든 것이 빠르게 시작되지 못하게하여 몇 가지 흥미로운 오류가 발생했습니다.
Rob

4
선량. 이것은 나를 화나게했다. 내가 언급 한 문서에서 읽은 것은 없습니다. 나는 AWS AMI를 선호하기 때문에 CoreOS를 거의 맹세했습니다. (AWS AMI는 기본적으로 Docker 데몬을 자동으로 시작합니다).
Nostalg.io

2
CoreOS가 전용 Docker OS이고 부팅하는 동안 docker를 시작하지 않는다는 점을 감안할 때 CoreOS가 이런 식으로 동작하는 것은 매우 드문 일입니까 ???
typelogic

3
이것은 매우 중요한 정보입니다. CoreOS 문서에는 Docker (또는 그 문제에 대한 다른 컨테이너 런타임)를 활성화 해야하는 것에 대해서는 언급하지 않았습니다. 베어 CoreOS에서 도커 컨테이너를 시작할 수 있고 (CoreOS가 컨테이너를 실행하도록 만들어 졌기 때문에) 기본 설정이라는 인상을 받았습니다. 첫 번째 업데이트 트리거 재부팅이 컨테이너를 시작하지 않을 때만 실수를 깨달았습니다.
Florian von Stosch

6

이것은 조금 오래되었지만 모든 새 서버 에서이 작업을 수행하기 위해 cloud-init를 사용하기 시작했습니다. 모든 서버에 사용하는 저장된 cloud-init 스크립트가 있습니다. 그것의 일부는 다음을 포함합니다 :

#cloud-config
coreos:
  units:
    - name: "docker.service"
      command: "start"
      enable: true

이렇게하면 도커 서비스가 활성화되고 처음 부팅 할 때마다 시작됩니다.


2

이미 설명한 바와 같이 이 의견 에 의해 , 고정 표시기 소켓 활성화됩니다. 즉, 데몬은 호출되지 않으면 시작되지 않습니다. 여기에있는 기존 답변이 작동하지만 CoreOS는 다른 접근법을 권장합니다.

CoreOS 설명서 에 따르면 권장되는 방법 은 자체 앱에 대한 서비스를 생성하고 Docker 서비스가 필요하다는 것입니다.

/etc/systemd/system/myapp.service :

[Unit]
Description=MyApp
After=docker.service
Requires=docker.service

[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill busybox1
ExecStartPre=-/usr/bin/docker rm busybox1
ExecStartPre=/usr/bin/docker pull busybox
ExecStart=/usr/bin/docker run --name busybox1 busybox /bin/sh -c "trap 'exit 0' INT TERM; while true; do echo Hello World; sleep 1; done"

[Install]
WantedBy=multi-user.target

대신 해당 서비스가 자동으로 시작되도록하십시오.

$ sudo systemctl enable /etc/systemd/system/myapp.service
$ sudo systemctl start hello.service

사용 사례는 서비스가 시작되면 컨테이너를 최신 버전으로 업데이트하고 고급 예제는 etcd에 서비스를 등록하는 것입니다. 자세한 배경 정보 는 CoreOS 설명서 를 읽으십시오 .


이것이 CoreOS의 "최신"입니까? Docker는 몇 년 동안 다시 시작 정책을 가지고 있었으므로 더 이상 필요하지 않거나 바람직하지 않습니다. 실제로는 바람직하지 않았지만 Docker가 컨테이너 자체를 다시 시작하는 데 대한 지원이 (아주 오래된 버전) 해결 방법이었습니다. CoreOS 사용을 중단하는 데 오랜 시간이 걸렸다 고 생각합니다.
Michael Hampton

@MichaelHampton 다시 시작 정책은 컨테이너가 다른 이유로 충돌하는 경우에도 적용되므로 다른 정책을 대체하지는 않습니다. 게다가 재시작 정책으로 부팅시 컨테이너를 업데이트 할 수 없습니다. 어느 것이 더 좋은지 잘 모르겠지만이 방법을 사용하면 조금 더 제어 할 수 있다고 생각합니다.
Neograph734

1
많은 제어가 필요할 때 일반적으로 오케스트레이션 서비스에서 제공하는 다른 비트들도 필요합니다 : 간단한 엔드 도커 작성에서 Kubernetes까지
Michael Hampton

1

Docker Swarm을 사용하고 있으므로 systemd를 담당 할 특정 앱이 없습니다 ... 부팅을 시작하려면 docker가 필요합니다. 이것이 내가 해결 한 솔루션입니다.

이것을 넣어 /etc/systemd/system/poke-docker.service:

[Unit]
After=default.target

[Service]
Type=oneshot
ExecStart=/usr/bin/docker version
RemainAfterExit=yes

[Install]
WantedBy=default.target

그런 다음 systemctl enable poke-docker시동 순서가 끝날 때마다 부팅 할 때마다 트리거되도록 설정하십시오. 이 docker version명령은 docker 데몬과 통신하여 소켓을 트리거하고 docker 서비스 자체를 시작합니다.

나는 systemctl enable docker다른 대답으로 트릭을 시도했지만 처음에는 효과가 있었지만 Docker가 분명히 많은 일을하려고하고 비참하게 실패하는 일종의 천둥 무리 상황을 일으킨 것으로 보입니다. 나는 이것이 의견에 언급 된 "부트 체인 차단"동작이라고 생각합니다.


웜랩에서 gitlab-runner를 실행하는 동일한 사용 사례가 있습니다. 이것은 확실히 데몬을 깨 웁니다. 점화 파일 coreos.com/os/docs/latest/using-systemd-drop-in-units.html
drgn
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.