Различные локальные значения и основные значения для настроек сеанса PHP
Мы работаем над кодом, который выполняет следующие действия с использованием terraform (на AWS):
- Создает экземпляр core-os (1) с файлом yaml облачной конфигурации мы предоставили
- Создает AMI из этого экземпляра
Процесс работает отлично до сих пор.
Когда мы запускаем экземпляр (2) из этого AMI через консоль AWS. Вновь запущенный экземпляр не использует файл конфигурации облака.
Он (2) имеет единицы services / systemd, которые были созданы в экземпляре (1) с помощью файла yaml облачной конфигурации. Но эти службы мертвы. Они работают отлично, если мы запускаем их явно с помощью systemctl
Как мы можем убедиться, что ЛЮБОЙ экземпляр, созданный из этого AMI, должен запускать эти модули services / systemd при запуске или должен загружать этот файл облачной конфигурации?
(У нас есть этот 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
Мне не хватало того, что первая инстанция (1) использовала скрипт в качестве пользовательских данных, который затем запускал конфигурацию облака через команду cloud-config.
Вместо этого мне пришлось скопировать свою конфигурацию облака в /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 реализует многопользовательский.target), но он будет работать на последующих Ботинки. Также, делая снимок, убедитесь, что вы удалили /etc/машина и раньше. В противном случае, все машины будут иметь одинаковый ID.
ссылка: звено
Вам не нужно делать свой собственный AMI из коробки CoreOS, просто используйте официальный CoreOS AMI. Передавая один и тот же облачно-конфигурированный файл в каждый создаваемый вами бокс, вы запустите устройства. Это делает вашу инфраструктуру более непреложной, чем если бы вам пришлось делать снимки.
.