CoreOS: Is it possible to start an unit with cloud-init, which is manageable by fleet? - coreos

Question

Can I start units with cloud-init, so that they are manageable by fleet afterwards?
It seems, that only normal systemd services can be started by cloud-unit, but without having them under fleet control. Is this right?
What would be a possible solution to automatically start specific services after the cluster is bootstrapped?
SOLVED:
#cloud-config
write_files:
- path: /home/core/foo.service
owner: core:core
permissions: 0644
content: |
[Unit]
Description=Foo
Requires=docker.service
After=docker.service
[Service]
User=core
TimeoutStartSec=0
KillMode=none
EnvironmentFile=/etc/environment
ExecStartPre=-/usr/bin/docker kill foo
ExecStartPre=-/usr/bin/docker rm foo
ExecStartPre=/usr/bin/docker pull registry.example.com/foo
ExecStart=/usr/bin/docker run --name foo registry.example.com/foo
ExecStop=/usr/bin/docker stop foo
coreos:
etcd:
discovery: https://discovery.etcd.io/<token>
addr: $private_ipv4:4001
peer-addr: $private_ipv4:7001
units:
- name: etcd.service
command: start
- name: fleet.service
command: start
- name: auto-start-foo.service
command: start
content: |
[Unit]
Description=Autostarts foo-service
Requires=docker.service
After=docker.service
[Service]
WorkingDirectory=/home/core/
ExecStart=/usr/bin/fleetctl start foo.service
Type=oneshot

Answer 1

A few weeks ago I was wondering the same thing. The approach presented by the OP used fleetctl to launch the process. I think that had the affect of being able to do fleetctl list-units and the launched process would be listed and managed by fleet.
You could put the content from the write_files down in the units: section and get rid of the write_files section, like this:
#cloud-config
coreos:
etcd:
discovery: https://discovery.etcd.io/<token>
addr: $private_ipv4:4001
peer-addr: $private_ipv4:7001
units:
- name: etcd.service
command: start
- name: fleet.service
command: start
- name: foo.service
command: start
content: |
[Unit]
Description=Foo
Requires=docker.service
After=docker.service
[Service]
User=core
TimeoutStartSec=0
KillMode=none
EnvironmentFile=/etc/environment
ExecStartPre=-/usr/bin/docker kill foo
ExecStartPre=-/usr/bin/docker rm foo
ExecStartPre=/usr/bin/docker pull registry.example.com/foo
ExecStart=/usr/bin/docker run --name foo registry.example.com/foo
ExecStop=/usr/bin/docker stop foo
but, that does mean that:
you won't see the unit when you do a fleetctl list-units, it is being
managed by the underlying systemd.
if the unit fails because this host fails it won't migrate to another
fleet host.
Thank you for the great question and answer #mbo :-)