does linode support cloud init on linode creation?
13 Replies
Can you clarify what you mean by "pass user-data to cloud init when linode is created"? Like, what is the exact process?
If I do understand correctly, though, you're trying to automate deploying servers, which is something that can be done using stackscripts as you suspected. There are other tools that can help with this on our platform as well, such as Vagrant:
If I'm off the mark or if you need a bit more information please let me know!
@sohsoh5:
Hello Marketsys,
Can you clarify what you mean by "pass user-data to cloud init when linode is created"? Like, what is the exact process?
If I do understand correctly, though, you're trying to automate deploying servers, which is something that can be done using stackscripts as you suspected. There are other tools that can help with this on our platform as well, such as Vagrant:
https://www.linode.com/docs/application … vironments">https://www.linode.com/docs/applications/configuration-management/vagrant-linode-environments If I'm off the mark or if you need a bit more information please let me know!
He is referring to providing Cloud-Config to the cloud-init application that is available on Ubuntu (edited: not only
Digital Ocean supports that as "droplet metadata" (they call "User Data"): when you are creating a droplet, in the web panel you paste your cloud-config data and it is run automatically on droplet creation.
This is part of one of my "User Data" that I use when automatically deploying nodes for CI. Does Linode support something like that?
~~http://i.imgur.com/IcsABbK.png
#cloud-config
swap:
size: auto
filename: /swapfile
maxsize: 4G
users:
- name: gitlab-runner
ssh-authorized-keys:
- <your_key1>
- <your_key2>
sudo: ['ALL=(ALL) NOPASSWD:ALL']
groups: sudo
shell: /bin/bash
write_files:
- path: /etc/systemd/system.conf.d/10-default-env.conf
content: |
[Manager]
DefaultEnvironment=LC_ALL=en_US.UTF-8
- path: /etc/profile.d/env.sh
content: |
export LC_ALL=en_US.UTF-8
runcmd:
- sed -i -e '/^PermitRootLogin/s/^.*$/PermitRootLogin no/' /etc/ssh/sshd_config
- sed -i -e '$aAllowUsers gitlab-runner' /etc/ssh/sshd_config
- service ssh restart
- update-locale LC_ALL=en_US.UTF-8</your_key2></your_key1>
~~
@dwfreed:
it looks like you could make a simple StackScript to install cloud-init, dump your desired config into a file, and then initiate cloud-init with that file.
That's what I was thinking about, but cloud-init runs once on the first boot of custom images (EC2 also has support for cloud-config directly into the panel when creating images), so I still didn't find how to actually install and run it on 1st boot manually.
For manually running it, there are these 2 not-so-helpful topics (and nothing in the official docs):
But I still didn't find where I would place the cloud-config.yml file and still didn't find out how to run ONLY my script once.
@dwfreed:
Stackscripts are already run-only-once. This is implemented by moving aside the getty binary, and putting a small script in its place which executes your stackscript, then puts the getty binary back and then executes that (this is why they run after all initscripts). It looks like you'd just run 'cloud-init modules –mode config cloud-config.yml' where 'cloud-config.yml' contains your config (which you can have the StackScript take as input in the Linode Manager/API and then inject that into a file).
Awesome! I'll give that a try, thank you!
@jamix:
For us, a big disadvantage of Stackscripts is that you can't deploy an image with them. DigitalOcean allows you to deploy a master image via the API and then do any extra customizations with cloud-config. This is also discussed here:
https://forum.linode.com/viewtopic.php?f=20&t=11899
Why not clone a gold image then use a script to customize it? You can skip all the vagrant/puppet/salt/ansible crap then.
I realize this conversation has gone stale, but for the sake of anyone that visits this..
I created a StackScript that takes a userdata variable (which must be a base64 encoded userdata file).
https://www.linode.com/stackscripts/view/392559
$ pip install linode-cli
$ read -s -p "password: " ROOT_PASS; echo
$ linode-cli linodes create \
--root_pass=${ROOT_PASS} \
--label=cloudinittest \
--stackscript_id=392559 \
--stackscript_data='{"userdata":"'$(base64 -i /tmp/user-data)'"}'
The implementation is similar to @dwfreed's recommendation :-D
FWIW Ubuntu are now promoting cloud-init as a cross-platform industry standard for establishing known images. It's that notion that brought me here looking for Linode support.
I wish I could attach a PDF (I don't have a link):
As a technology business decision maker you have a great deal of choice today
when it comes to both open source operating systems and cloud execution
environments (or just clouds) to run those operating systems on. We are using the
term ‘cloud’ here in its widest possible sense: from private cloud (i.e. an
automated data centre), through hybrid to public cloud.
A common desire is to select the operating system which best supports your
application stack and then be able to use that operating system as an abstraction
layer between different clouds.
However, in order to function together an operating system and its cloud must
share some critical configuration data which tells the operating system how to
‘behave’ in the particular environment. By separating configuration data, one can
avoid the tight coupling of operating system and cloud, or to use the more
common industry term ‘locked-in’.
Cloud-init provides a mechanism for separating out configuration data from both
the operating system and the execution environment so that you maintain the
ability to change either at any time. It serves as a useful abstraction which ensures
that the investments you make in your application stack on a specific operating
system can be leveraged across multiple clouds.
Cloud-init is the industry standard method for cross-platform cloud instance
initialisation. It is supported by all major public cloud providers, provisioning
systems for private cloud infrastructure, and bare-metal installation. It enables
the automated provisioning of an operating system image (which is simply the
collection of packages) into a fully running state, complete with required access
and applications. Typical task handled by cloud-init include networking and
storage initialisation, optional package installation and configuration, user
account creation and security key provisioning for remote access. cloud-init can
these task within the first boot of an instance. This prevents end users from
needing to spend time producing and maintaining images that are out-of-date,
require building, and maintenance. Instead cloud-init does run in most operating
systems each time a new instance is launched, independently from image source.
This level of configuration is provided by cloud-init across all major Linux
distributions and FreeBSD. With current support provided in the following.
• Ubuntu
• SLES/openSUSE
• RHEL/CentOS
• Fedora
• Gentoo Linux
• Debian
• ArchLinux
• FreeBSD
Cloud-init provides support across a wide ranging list of execution environments:
• Amazon
• GCP
• Rackspace
• Digital Ocean
• Azure
• Etc etc
I just created a linode based on the Alpine 3.15 image, and it is running cloud-init.
Poking around in the logs, it is running against datasource:DataSourceNone, which leaves me to believe at this point it is not being initialized with any meta data.
Also, the logs are running at the DEBUG level, which looks like this probably was not meant to be in a production image as you don't normally log at DEBUG level in prod.
Just some observations, it would be cool if this did function.
Probably necro thread, but we are being asked to look into moving to Linode and cloud-init is a fundamental component of our multi-cloud standardization.
When will Linode launch instances so that /run/cloud-init/instance-data.json contains the relevant v1 keys for an instance?
Specifically the non-user-provided ones such as region, instance id, platform, etc…
