Launch a RancherOS instance with cloud-init

When launching one of the RnacherOS AMIs, I would like to be able to use cloud-init to launch rancher-server. From experimenting with this, and having read the documentation, I’m not sure that it’s currently possible.

I’ve tred to use a cloud-init file which looks like this:


 - docker run -d --restart=always -p 8080:8080 rancher/server

I wonder if anybody has any thoughts on this, particularly if there are any good reasons why I shouldn’t be trying to get this running!


Hi @philpowell,

Use the following cloud-config as your instance’s user data to start Rancher Server:

      image: rancher/server
      restart: always
      - 8080:8080


In fact, you can specify your services just using compose format (just use #compose as the header), like this:

  image: rancher/server
  restart: always
  - 8080:8080

Brilliant! Thank you. I will try this out later today.

I’m still getting tripped up by this a little, and I think I need to understand a bit more about how cloud-init is being initiated.

When I use the #cloud-config config, the EC2 instance starts up fine, but the cloud-init doesn’t appear to be initiated. There’s no sign of any unusual activity in /var/log/docker.log.

When I use the #compose config, it doesn’t appear to initiate, and I’m unable to access the instance through SSH (I install a key when the instance is fired up). The SSH connection is refused, so it seems as though this config is conflicting with the startup of the instance — it’s difficult for me to determine what’s happening though, when I’m unable to access the instance.

I’m wondering if I’m missing something glaringly obvious?

Actually, a correction: it looks as though the #cloud-config config is also preventing SSH from starting up. So I can only assume that the cloud-init is overriding any and all services which EC2 might have been starting by default. But Rancher still doesn’t look like it’s started up.

Well, it turns out that — as with most things in life — I simply wasn’t being patient enough! Both of those configuration methods worked: it just took a little longer for the instance to fire up it’s services than usual. I’m curious to know why that is, but I’m sure I can glean something from the logs.

Thanks for your help with this @imikushin

@philpowell It probably took some time as the rancher/server image needed to be downloaded from Docker and on to your host. At least that’s what my guess would be.

Yes, I hadn’t properly appreciated the amount of time it would take for the image to be pulled. I’m very happy that the server can be started as soon as the instance starts up though — we are now able to provision and start up a Rancher server with a single command.

How could this pull from a private repo during cloud-init? Where would it look for the .dockercfg?

I guess if you wanted to pull a private image, you could provide a command in cloud-init to populate your .dockercfg with the appropriate credentials. I think you’d probably be looking at runcmd for that though, and I’m not 100% sure the Rancher flavour of cloud-init on the AMI supports that (it’s where I ran into trouble first time around).

FYI for anyone who comes across this:

There is no runcmd subset of cloud-init in RancherOS (yet…) as far as I understand.

runcmd is executed at the run level before the docker service is started.

Reference: When using runcmd, RancherOS will wait for all commands to complete before starting Docker

[rancher@ip-172-31-8-65 ~]$ sudo system-docker ps
CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS              PORTS               NAMES
61cbe4279219        rancher/os-console:v0.8.0   "/usr/bin/ros entrypo"   3 weeks ago         Up 3 weeks                              console
ef4b6a51a53b        rancher/os-docker:1.12.6    "ros user-docker"        3 weeks ago         Up 3 weeks                              docker

To run docker commands on system bootup, can create /etc/rc.local file, or other run level startup scripts

This is a good guide:

The best way to do this is to define a in the #cloud-init as suggested by @imikushin

just two month ago (as I’m writing this comment), rancher also introduced a new parameter awslocal to the –advertise-address parameter, hence you could start rancher in HA mode on startup, through defining in #cloud-init


    - /dev/vdb
    - /mnt
    - ext4
    - ""

  - $key

      image: rancher/server:stable
      restart: unless-stopped
        - --db-host
        - $mariadb_ip
        - --db-user
        - $cattle_user
        - --db-pass
        - $cattle_password
        - --db-name
        - $cattle_db
        - --advertise-address
        - awslocal
        - 8080:8080
        - 9345:9345

This is the change that introduced awslocal

1 Like