Файл конфигурации облака не загружен, и устройства не запущены на машине, созданной из AMI

Мы работаем над кодом, который выполняет следующие действия с использованием terraform (в AWS):

  1. Создает экземпляр core-os (1) с предоставленным нами файлом yaml cloud-config
  2. Создает AMI из этого экземпляра

Процесс прекрасно работает до сих пор.

Когда мы запускаем экземпляр (2) из ​​этого AMI через консоль AWS. Недавно запущенный экземпляр не использует файл конфигурации облака.

У него (2) есть сервисы / системные модули, которые были созданы в экземпляре (1) посредством файла yaml cloud-config. Но эти услуги мертвы. Они прекрасно работают, если мы начнем их явно, используя systemctl

Как мы можем убедиться, что ЛЮБОЙ экземпляр, созданный из этого AMI, должен запускать эти сервисы / системные модули при запуске или загружать этот файл конфигурации облака?

(У нас этот облачный конфигурационный файл yaml также сохранен в расположении внутри машины, если мы запускаем файл облачного конфигурационного файла вручную через coreos-cloudinit --from-file=path/to/file/cloud-config.yamlвсе отлично работает. Но мы хотим, чтобы он работал при запуске без ручного шага)

Вот наш файл конфигурации облака

#cloud-config
coreos:
  etcd2:
    # generate a new token for each unique cluster from https://discovery.etcd.io/new?size=3
    # specify the initial size of your cluster with ?size=X
    discovery: https://discovery.etcd.io/2cb27f1fecb57e14837016e04547aa32
    # multi-region and multi-cloud deployments need to use $public_ipv4
    advertise-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001
    initial-advertise-peer-urls: http://127.0.0.1:2380
    # listen on both the official ports and the legacy ports
    # legacy ports can be omitted if your application doesn't depend on them
    listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001
    listen-peer-urls: http://0.0.0.0:2380,http://0.0.0.0:7001
  units:
    - name: etcd2.service
      command: start
    - name: fleet.service
      command: start
    - name: hello.service
      command: start
      content: |
        [Unit]
        Description=hello_docker
        After=docker.service
        Requires=docker.service

        [Service]
        TimeoutStartSec=0
        ExecStartPre=-/usr/bin/docker rm busybox1
        ExecStartPre=/usr/bin/docker pull busybox
        ExecStart=/usr/bin/docker run --rm --name busybox1 busybox /bin/sh -c "while true; do echo Hello Docker; sleep 1; done"
        ExecStop=/usr/bin/docker stop busybox1
Источник

2 ответа

Решение

Чего мне не хватало, так это того, что первый экземпляр (1) использовал скрипт в качестве пользовательских данных, который затем запускал cloud-config с помощью команды cloud-init.

Вместо этого мне пришлось скопировать свою конфигурацию облака в /usr/share/oem/, чтобы экземпляр, созданный AMI, также использовал эту конфигурацию облака по умолчанию.

Более того, следующее может помочь кому-то, столкнувшемуся с подобной проблемой, но оно не запустится при первой загрузке, как уже упоминалось.

Вам необходимо активировать сервисы (убедитесь, что у них есть разделы Install).

#cloud-config

coreos:
  units:
    - name: "example.service"
      enable: true
      content: |
        [Service]
        Type=oneshot
        ExecStart=/usr/bin/echo Hello World

        [Install]
        WantedBy=multi-user.target

Эта служба не запускается при первой загрузке (поскольку модуль активируется после того, как systemd реализует multi-user.target), но будет работать при последующих загрузках.

Кроме того, при создании снимка убедитесь, что вы удалили / etc / machine-id ранее. В противном случае все машины будут иметь одинаковый идентификатор.

ссылка: ссылка

Источник

Вам не нужно создавать свой собственный AMI для CoreOS, просто используйте официальные CoreI AMI. Передача одного и того же файла конфигурации облака в каждый ящик, который вы хотите создать, и модули будут запущены. Это делает вашу инфраструктуру более неизменной, чем если вы должны делать снимки.

Источник
Другие вопросы по тегам