I boot the rancher.iso with a persistent RANCHER_STATE drive. I want to have the state saved between boots but not images, they should be pulled every time. Would it be possible to fex mount the images.tar on tmpfs during boot?
Heya,
I’m not really sure what you mean - most of the state I have is in containers - and those are tied to the image - re-pulling the image means recreating the container.
So solutions to your request may be specific to what you’re doing 
I thought that if an image is missing when a container starts, then it is pulled from the repository. Are you saying that the container would just fail to start?
no, I’m not saying that - and now I’m even less clear what you’re asking about.
can you give us more information?
Lets say I have a host with plenty of ram but no writable disk storage. I could still boot the rancher.iso, do some configurations like setting static ip, hostname, dns etc. I could even start up some containers.
Now if I would like to preserve those kilobytes of configuration to a very small persistent disk storage? No, that just isn’t possible because, for some reason i can not understand, along with the kilobytes of configuration I have to store hundreds of megabytes of image files. Image files that don’t contain any system unique information and which could easily be restored from another persistent storage, that is the repository.
So I’m just asking, is there a way to preserve all host unique configuration between boots and let the redundant docker images stay in their repositories?
I wonder if what you really need, is a cloud-config.yml that contains the small amount of cfg info?
I there a way to pass a cloud-config when booting the rancher.iso?
I’ve tried to create a config-drive to pass cloud-config when booting rancheros.iso without persistence.
I created the config-drive by booting a Gparted iso and execute following:
mkfs.vfat -n config-2 -I /dev/sda
mkdir -p /media/config-drive
mount /dev/sda /media/config-drive
mkdir -p /media/config-drive/openstack/latest
cp cloud-config.yml /media/config-drive/openstack/latest/user_data
umount /media/config-drive
The user_data file:
#cloud-config
hostname: test
Then I modified the rancheros.iso (v0.7.1) kernel parameters in /boot/isolinux/isolinux.cfg:
default rancheros
label rancheros
kernel /boot/vmlinuz
initrd /boot/initrd
append quiet rancher.autologin=tty1 rancher.autologin=ttyS0 rancher.password=test rancher.cloud_init.datasources=[configdrive:/media/config-2]
But when I boot the modified rancheros.iso the hostname is still rancher and /media/config-2 is not mounted.
Have I done anything wrong or is the rancher.cloud_init.datasources kernel parameter simply not working with the rancheros.iso? Please help.
Edit:
I’ve also tried to copy /openstack/latest/user_data to the iso and labeling it config-2 but the config wasn’t read then either.
There’s no need to modify the ISO for a config-drive. RancherOS will automatically use it if it’s detected during boot.
Our test script (https://github.com/rancher/os/blob/master/scripts/run#L163) is probably the best resource to look at how this is done. We don’t have documentation on this unfortunately. It is fully compatible with OpenStack config-drive so you could probably find docs on that elsewhere.
I’ve followed these instructions:
https://coreos.com/os/docs/1284.2.0/config-drive.html
https://gist.github.com/itzg/608cad532cb61d6b6c10
But as I said, the config-drive isn’t detected when booting rancher.iso.
Should I report it as a bug?
Nevermind, it works. It seems that the user_data file must not end with an empty line.
that doesn’t sound very friendly - would you be interested in filing a bug at https://github.com/rancher/os ?
Now I’m unable to reproduce the error. Guess it wasn’t the new line after all.
Using the boot iso as a config-drive works fine.
But using a fat partition as a config-drive does not work. During boot I get:
FAT-fs (sda): IO charset iso8859-1 not found
I’m able to mount the fat partition at the console by using the iocharset=utf8 mount option but how can I make it mount during boot?
If only rancheros.iso could read a fat formatted config-drive then I wouldn’t need to edit the iso at all. Changing RancherOS version on the server would be effortless. Should I file a bug?
Update:
This is already mentioned in issue #1217:
Seems kernel/fs/fat/vfat.ko, kernel/fs/fat/fat.ko, kernel/fs/fat/vfat.ko and kernel/fs/nls/nls_cp437.ko are missing in 4.4.19-rancher kernel
Until fat booting is fixed in RancherOS, this is my semi-persistent setup:
/openstack/latest/user_data on rancheros.iso (labeled config-2):
#!/bin/sh
mkdir -p /home/rancher/conf
mount -t ext4 /dev/disk/by-label/conf /home/rancher/conf
chmod 7700 /home/rancher/conf
touch /home/rancher/conf/cloud-config.yml
chmod 7600 /home/rancher/conf/cloud-config.yml
touch /home/rancher/conf/rc.local
chmod 7700 /home/rancher/conf/rc.local
touch /etc/rc.local
mount -o bind /home/rancher/conf/rc.local /etc/rc.local
mkdir -p /var/lib/rancher/state
mount -o bind /home/rancher/conf/state /var/lib/rancher/state
ros config merge < /home/rancher/conf/cloud-config.yml
ros service restart network-pre
/bin/sh -c "ros service create && ros service start" &
/home/rancher/conf/cloud-config.yml on conf disk:
#cloud-config
hostname: rancherhost1
rancher:
network:
dns:
nameservers:
- <Add nameserver ip!>
search:
- <Add search address!>
interfaces:
eth0:
address: <Add host ip or remove!>
gateway: <Add gateway or remove!>
dhcp: <Set false or true!>
mtu: <Set mtu or remove!>
services:
rancher-agent1:
command: http://<rancher-server:port>/v1/scripts<Add keys!>
image: rancher/agent:latest
environment:
- CATTLE_HOST_LABELS=<Add label key!>=<Add label value!>&<Add label key!>=<Add label value!>&...
privileged: true
volumes:
- /var/run/docker.sock:/var/run/docker.sock
ssh:
keys:
<Add keys here!>
/home/rancher/conf/rc.local on conf disk:
#!/bin/sh
echo 'rancher:<Add password!>' | chpasswd
wait-for-docker
Observe that /home/rancher/conf/state must contain .docker_uuid, .physical_host_uuid and .registration_token. Copy those three files from a temporary, running rancher agent. Comments and improvements are welcome.