Cloud-init is a standard way to initialize VPS instances starting from OS images on VMs on first boot. I use it to initialize everything on the VM required to run the desired applications. So for example you can set up the following options using cloud-init:

• hostname
• users and auth keys
• timezone
• installation and configuration of software
• database setup
• …

Much more is possible – consult the official documentation for everything else.

You provide your own options as a chunk of .yaml as so called user data which is everything you decide in addition to everything the hosting provider decides. As you can write files and run shell commands as part of your yaml-recipe the possibilities are endless.

I ran my cloud-init recipes successfully on

• ProxMox VM
• Hetzner Cloud

Example

This ist an example cloud-init recipe

#cloud-config
hostname: example
manage_etc_hosts: true
ssh_authorized_keys:
  - ...
chpasswd:
  expire: false
users:
  - default
disable_root: false
timezone: Europe/Berlin
apt:
  sources:
    suryphp:
      source: ppa:ondrej/php
package_upgrade: true
packages:
  - apt-transport-https
  - mailutils
  - git
  - curl
  - rsnapshot
  - screen
...

To explore

Cloud-init is a standard to initialize cloud instances.

But for some setups a baremetal server is still the best option. For example you usually get the most power for the best price using baremetal. So it would be great to reuse your tested cloud-init recipes on baremetal systems. I assume that it should be possible using the NoCloud datasource. But the hosting provider of your choice has to support getting that user-data config into the OS image. For Ubuntu this should be possible using autoinstall.

So you have a setup where Nextcloud runs on a host with internal IP which is exposed to the public network using a reverse proxy like Nginx. Public URLs are not accessible from the internal network due to DNS resolution. Research shows that this setup seems to be quite common.

Next you want to integrate Collabora Office into Nextcloud to allow editing of office documents. First steps are to install the Nextcloud app „richdocuments“ then install the coolwsd service which provides Collabora Office. We switch off SSL in coolwsd as it is provided by the reverse proxy. Internally HTTP can be used.

Now you have 2 separate services which send requests to each other so both have to reach the other service but we can’t use public URLs as they are not reachable internally.

Next you find a quick overview how to setup this scenario:

• There are 3 URLs in Nextcloud’s richdocuments which have to be setup using the console as 2 of them are not available in the UI. For internal communication we use HTTP so we don’t have to deal with certificates.
  • public_wopi_url is the public URL of your Nextcloud instance, e.g. https://nextcloud.example.com
    • sudo -u www-data php ./occ config:app:set richdocuments public_wopi_url --value https://nextcloud.example.com
  • wopi_callback_url is the internal URL of your Nextcloud instance, e.g. http://192.168.201.102
    • sudo -u www-data php ./occ config:app:set richdocuments wopi_callback_url --value http://192.168.201.102
  • wopi_url is the internal URL of coolwsd, e.g. http://192.168.201.102:9980
    • sudo -u www-data php ./occ config:app:set richdocuments wopi_url --value http://192.168.201.102:9980

This way both services can reach each other internally.

Integration works by including Collabora in an iframe in our Nextcloud instance. So we have to extend the Content Security Policy (CSP) of coolwsd as its directive frame-ancestors by default only includes wopi_callback_url which is not publicly reachable. We can set it in /etc/coolwsd/coolwsd.xml:

<frame_ancestors desc="OBSOLETE: Use content_security_policy. Specify who is allowed to embed the Collabora Online iframe (coolwsd and WOPI host are always allowed). Separate multiple hosts by space.">https://nextcloud.example.com 'self'</frame_ancestors>

The hint regarding frame_ancestors being obsolete might be correct but i found that only by using frame_ancestors i got a correct CSP-policy. Using content_security_policy created 2 policies which prevent loading the iframe. I will put an issue on github.

For device testing a client needed a solution to set devices reliably to a time in the future to trigger certificate renewal and similar processes.

We agreed that providing a mock time via a NTP service would be a good solution. One requirement was to have the NTP service run in a Docker container.

I explored the space of NTP services and if in one of those the time could be set freely but didn’t have any luck finding such a solution. What i found was that for some NTP services the local time could be used as time source. But as we wanted to run the NTP server in a Docker container changing the local time was not possible.

After considering different approaches i came up with the following solution:

• use the NTP service chrony as it has a simple configuration and works with Docker
• for computers without network connectivity chrony can use the local time as time source and appear synchronized
• use libfaketime to deliver freely settable local time to single processes without changing the local time. For newly started programs libfaketime is loaded via library preloading and answers the system calls of those programs with fake time.

I put it all together and put my solution for running a NTP service with fake time as Docker container on github.

These days i have the pleasure to upgrade an application running on AWS Elastic Beanstalk from platform Multi-container Docker to new platform Docker. The former is based on Amazon Linux 1 (AL1) while the latter runs on Amazon Linux 2 (AL2). I follow this guide.

I have encountered the following advantages so far:

• links between containers are now fully bidirectional: on AL1 those links could only be defined and used in one direction. If you wanted bidirectional communication you had to implement service discovery yourself
• the limit on 10 containers per app is gone: in my tests i could easily spin up 12 containers.
  • apparently this limitation came from the automatic translation of an Elastic Beanstalk app into a task definition. The limitation is documented as task definition max containers.
  • on AL1 one got the following error:

frontend-staging - ERROR: Service:AmazonECS, Code:ClientException, Message:Too many containers., Class:com.amazonaws.services.ecs.model.ClientException

• i could restart single containers without affecting the other running containers: on AL1 this would cause a restart of all containers for reasons unknown to me.
• simplified logging – all services log to /var/log/eb-docker/containers/eb-current-app/eb-stdouterr.log which can be streamed to CloudWatch.