2

This is my default cloud-init

package_update: true
package_upgrade: true
users:
  - name: sammy
    ssh_authorized_keys:
      - ssh-rsa AAAAB3NzaC1...
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    groups: sudo
    shell: /bin/bash
write_files:
  - path: /etc/issue.root
    content: |
      SSH access for root is blocked. Please use xxx instead.
  - path: /etc/issue.everybody
    content: |
      Welcome! This Ubuntu 22.04 is spun up by xxx using DigitalOcean APIv2.

runcmd:

  • | curl https://events.hookdeck.com/e/abc -X POST -d "{ "command": "configure-sshd-config" }"

I actually have more but i truncated the cloud-init yaml

i like to run curl https://events.hookdeck.com/e/abc -X POST -d "{ "event": "dependent on where i run this" }"

in some areas such as before/after adding the sammy user or before/after running the package upgrade and writing files.

I know how to do this easily within my long runcmd.

But i am unsure how to do this for non-runcmd.

The reason is I have a software that will call DigitalOcean API on behalf of my users who have DigitalOcean accounts.

I like to give them a progress bar and the only way I can do that is by calling curl on webhooks.

2 Answers2

2

This is not a feature of cloud-init (outside of reporting, as @falcojr noted).

Your question has already been answered by others, so I'll share some ancillary information related to how one can measure (and optimize) the performance of cloud-init. This won't get you your status bar, but maybe it will get you a faster boot time (which is often a motivation behind this kind of question).

Performance Tools:

If you are interested in better understanding or optimizing cloud-init boot time, there are some utilities you might consider.

cloud-init analyze: similar to systemd-analyze, it will show a breakdown of what cloud-init spent time on

systemd-analyze: shows a breakdown of what systemd spent time on

Optimization Strategy:

When trying to optimize a system boot time, I typically start by running systemd-analyze blame, looking at the most time-consuming service, and then asking myself: a) Do I need it? and if I do b) Is there anything I can do to make this faster?

Disable/reconfigure, rinse and repeat. If you don't know, don't guess. Do your research before gutting your OS.

Same with cloud-init analyze blame.

Typically there are only a few services worth looking at before you are considering services/modules that are under a second. I've run this a few times on my own servers and I typically find things like package install and updates as well as other network/disk intensive tasks take up the most time. It's easy to accidentally write a config that "works", but is also slow.

Quick Example:

I've seen some cloud-configs out there that do things like:

runcmd:
  - "apt-get install git"
  - "apt-get install neovim"

which won't perform nearly as well as the following (or the builtin module):

runcmd:
  - "apt-get install git neovim"

On a quick GCP test these two had a 3 second delta for me.

This example is simple, but since I've seen blog posts doing the former, my guess is this section might help somebody at some point :-)

1

My suggestion comes from these pages:

Roughly it is:

  • Create a bootcmd ( https://cloudinit.readthedocs.io/en/latest/topics/examples.html#run-commands-on-first-boot ) that polls until the network is up, then downloads and executes the next stage.
  • The second stage actively watches and processes log data (e.g. from: /var/log/cloud-init.log ) to evaluate where in the install process you are.
  • At that point, you can start sending updates using 'curl' or whatever tool makes the most sense as you see lines show up in the log files.

Potential challenges:

  • Requires programming.
  • Requires understanding the log files.

I suggest performing a few test installs and sending each line as it shows up (e.g. using 'curl') to get a sense what a 'normal' install looks like, finding some key points, and using those points to trigger your updates.