Skip to content

Commit 8ad52c8

Browse files
nasirhmnasirhm
authored
Add basic/intermediate and advanced provisioning tutorials (#134)
Tutorials imported from Dusty Mabe's Devconf.cz 2020 Fedora CoreOS Lab: https://dustymabe.com/2020/01/23/devconf.cz-2020-fedora-coreos-lab/ Fixes: #106
1 parent e8dfdc7 commit 8ad52c8

File tree

5 files changed

+761
-0
lines changed

5 files changed

+761
-0
lines changed

‎modules/ROOT/nav.adoc‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -34,3 +34,7 @@
3434
** xref:migrate-cl.adoc[Migrating from Container Linux]
3535
* Reference pages
3636
** xref:platforms.adoc[Platforms]
37+
* xref:tutorials.adoc[Tutorials]
38+
** xref:tutorial-basic-provisioning-and-customization.adoc[Basic Provisioning with Fedora CoreOS]
39+
** xref:tutorial-intermediate-provisioning.adoc[Intermediate Provisioning Scenario]
40+
** xref:tutorial-advanced-provisioning.adoc[Advanced Provisioning Scenario]

‎modules/ROOT/pages/tutorial-advanced-provisioning.adoc‎

Lines changed: 289 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,289 @@
1+
= Booting Fedora CoreOS: Advanced Provisioning Scenario
2+
3+
This tutorial begin where xref:intermediate-provisioning-tutorial.adoc[Intermediate Provisioning Tutorial] left off.
4+
Where we provisioned a Fedora CoreOS instance to add a systemd dropin, disable automatic updates, added an executable script to run on boot and configured a systemd service to run the script on first boot.
5+
6+
So, what is running a server all about? Hosting services, crunching data ? *DING DING DING!*
7+
Let's actually do something with out Fedora CoreOS node.
8+
9+
Since Fedora CoreOS is focused on running applications/services in containers we recommend trying to only run containers and not modifying the host directly.
10+
This makes automaic updates more reliable and allows for seperation of concerns with the Fedora CoreOS team responsible for the OS and end-user operators/sysadmins responsible for the applications.
11+
12+
In this case let's do a few more things. As usual we'll do the autologin and disabling of updates, but we'll also:
13+
14+
* Add an SSH Key fot the `core` user.
15+
* Add a systemd service (`failure.service`) that fails on boot.
16+
* Add a systemd service that will use a container to bring up a hosted service.
17+
18+
We'll create this config in a file called `./fcct-advanced.yaml`
19+
20+
[source,yaml]
21+
----
22+
[host]$ cat fcct-advanced.yaml
23+
variant: fcos
24+
version: 1.0.0
25+
passwd:
26+
users:
27+
- name: core
28+
ssh_authorized_keys:
29+
- ssh-rsa AAAA...
30+
systemd:
31+
units:
32+
- name: [email protected]
33+
dropins:
34+
- name: autologin-core.conf
35+
contents: |
36+
[Service]
37+
# Override Execstart in main unit
38+
ExecStart=
39+
# Add new Execstart with `-` prefix to ignore failure
40+
ExecStart=-/usr/sbin/agetty --autologin core --noclear %I $TERM
41+
TTYVTDisallocate=no
42+
- name: failure.service
43+
enabled: true
44+
contents: |
45+
[Service]
46+
Type=oneshot
47+
ExecStart=/usr/bin/false
48+
RemainAfterExit=yes
49+
[Install]
50+
WantedBy=multi-user.target
51+
- name: etcd-member.service
52+
enabled: true
53+
contents: |
54+
[Unit]
55+
Description=Run single node etcd
56+
After=network-online.target
57+
Wants=network-online.target
58+
[Service]
59+
ExecStartPre=mkdir -p /var/lib/etcd
60+
ExecStartPre=-/bin/podman kill etcd
61+
ExecStartPre=-/bin/podman rm etcd
62+
ExecStartPre=-/bin/podman pull quay.io/coreos/etcd
63+
ExecStart=/bin/podman run --name etcd --net=host \
64+
--volume /var/lib/etcd:/etcd-data:z \
65+
quay.io/coreos/etcd:latest /usr/local/bin/etcd \
66+
--data-dir /etcd-data --name node1 \
67+
--initial-advertise-peer-urls http://127.0.0.1:2380 \
68+
--listen-peer-urls http://127.0.0.1:2380 \
69+
--advertise-client-urls http://127.0.0.1:2379 \
70+
--listen-client-urls http://127.0.0.1:2379 \
71+
--initial-cluster node1=http://127.0.0.1:2380
72+
ExecStop=/bin/podman stop etcd
73+
[Install]
74+
WantedBy=multi-user.target
75+
storage:
76+
files:
77+
- path: /etc/zincati/config.d/90-disable-auto-updates.toml
78+
contents:
79+
inline: |
80+
[updates]
81+
enabled = false
82+
----
83+
84+
_Optional:_ You can replace the SSH pubkey in the yaml file with your own public key so you can log in to the booted instance. If you choose not to do this you'll still be auto logged in to the serial console.
85+
86+
Run `fcct` to convert that to an ignition config:
87+
88+
[source,bash]
89+
----
90+
[host]$ fcct --pretty --strict fcct-advanced.yaml --output advanced.ign
91+
----
92+
93+
Now let's provision it:
94+
95+
[source, bash]
96+
----
97+
[host]$ chcon --verbose unconfined_u:object_r:svirt_home_t:s0 advanced.ign
98+
[host]$ virt-install --name=fcos --vcpus=2 --ram=2048 --import \
99+
--network=bridge=virbr0 --graphics=none \
100+
--qemu-commandline="-fw_cfg name=opt/com.coreos/config,file=${PWD}/advanced.ign" \
101+
--disk=size=20,backing_store=${PWD}/fedora-coreos[stream_version].qcow2
102+
----
103+
104+
On the serial console you see:
105+
106+
[source,bash]
107+
----
108+
Fedora CoreOS preview 32.20200108.3.0
109+
Kernel 5.6.7-200.fc32.x86_64 on an x86_64 (ttyS0)
110+
111+
eth0: 192.168.122.163 fe80::5054:ff:fe73:6081
112+
localhost login: core (automatic login)
113+
114+
[systemd]
115+
Failed Units: 1
116+
failure.service
117+
----
118+
119+
If you’d like to connect via SSH disconnect from the serial console by pressing `CTRL` + `]` and then use the reported IP address for `eth0` from the serial console to log in using the `core` user via SSH:
120+
121+
[source,bash]
122+
----
123+
$ ssh [email protected]
124+
The authenticity of host '192.168.122.163 (192.168.122.163)' can't be established.
125+
ECDSA key fingerprint is SHA256:OAmR5Ab5eH9eZHC+D1gYmRsoUgJ/jufTNArrskBCxr4.
126+
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
127+
Warning: Permanently added '192.168.122.163' (ECDSA) to the list of known hosts.
128+
Fedora CoreOS preview 32.20200108.3.0
129+
Tracker: https://github.com/coreos/fedora-coreos-tracker
130+
Preview release: breaking changes may occur
131+
132+
Last login: Mon Jan 20 22:15:10 2020
133+
[systemd]
134+
Failed Units: 1
135+
failure.service
136+
----
137+
138+
*NOTE:* IP address can differ according to your network bridge settings.
139+
140+
The `Failed Units` message is coming from the https://github.com/coreos/console-login-helper-messages[console login helper messages] helpers.
141+
This particular helper shows us when `systemd` has services that are in a failed state.
142+
In this case we made `failure.service` with `ExecStart=/usr/bin/false`, so we intentionally created a service that will always fail in order to illustrate the helper messages.
143+
144+
Now that we’re up and we don’t have any real failures we can check out our service we care about (`etcd-member.service`):
145+
146+
[source,bash]
147+
----
148+
$ systemctl status etcd-member.service
149+
● etcd-member.service - Run single node etcd
150+
Loaded: loaded (/etc/systemd/system/etcd-member.service; enabled; vendor preset: enabled)
151+
Active: active (running) since Mon 2020-01-20 22:15:09 UTC; 4min 5s ago
152+
Process: 1144 ExecStartPre=/usr/bin/mkdir -p /var/lib/etcd (code=exited, status=0/SUCCESS)
153+
Process: 1153 ExecStartPre=/bin/podman kill etcd (code=exited, status=125)
154+
Process: 1356 ExecStartPre=/bin/podman rm etcd (code=exited, status=1/FAILURE)
155+
Process: 1396 ExecStartPre=/bin/podman pull quay.io/coreos/etcd (code=exited, status=0/SUCCESS)
156+
Main PID: 1971 (podman)
157+
Tasks: 10 (limit: 2297)
158+
Memory: 115.7M
159+
CGroup: /system.slice/etcd-member.service
160+
└─1971 /bin/podman run --name etcd --net=host --volume /var/lib/etcd:/etcd-data:z quay.io/coreos/etcd:latest /usr/local/bin/etcd --data-dir /etcd-data --name node1 --initial-adv>
161+
162+
Jan 20 22:15:10 localhost podman[1971]: 2020-01-20 22:15:10.486290 I | raft: b71f75320dc06a6c became candidate at term 2
163+
Jan 20 22:15:10 localhost podman[1971]: 2020-01-20 22:15:10.486327 I | raft: b71f75320dc06a6c received MsgVoteResp from b71f75320dc06a6c at term 2
164+
Jan 20 22:15:10 localhost podman[1971]: 2020-01-20 22:15:10.486344 I | raft: b71f75320dc06a6c became leader at term 2
165+
Jan 20 22:15:10 localhost podman[1971]: 2020-01-20 22:15:10.486351 I | raft: raft.node: b71f75320dc06a6c elected leader b71f75320dc06a6c at term 2
166+
Jan 20 22:15:10 localhost podman[1971]: 2020-01-20 22:15:10.486698 I | etcdserver: published {Name:node1 ClientURLs:[http://127.0.0.1:2379]} to cluster 1c45a069f3a1d796
167+
Jan 20 22:15:10 localhost podman[1971]: 2020-01-20 22:15:10.487238 I | etcdserver: setting up the initial cluster version to 3.3
168+
Jan 20 22:15:10 localhost podman[1971]: 2020-01-20 22:15:10.487310 I | embed: ready to serve client requests
169+
Jan 20 22:15:10 localhost podman[1971]: 2020-01-20 22:15:10.488046 N | embed: serving insecure client requests on 127.0.0.1:2379, this is strongly discouraged!
170+
Jan 20 22:15:10 localhost podman[1971]: 2020-01-20 22:15:10.498083 N | etcdserver/membership: set the initial cluster version to 3.3
171+
Jan 20 22:15:10 localhost podman[1971]: 2020-01-20 22:15:10.498521 I | etcdserver/api: enabled capabilities for version 3.3
172+
----
173+
174+
We can also inspect the state of the container that was run by the systemd service:
175+
176+
[source,bash]
177+
----
178+
$ sudo podman ps -a
179+
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
180+
85cf5d500626 quay.io/coreos/etcd:latest /usr/local/bin/et... 4 minutes ago Up 4 minutes ago etcd
181+
----
182+
183+
And we can set a key/value pair in etcd. For now let’s set the key `fedora` to the value `fun`:
184+
185+
[source,bash]
186+
----
187+
$ curl -L -X PUT http://127.0.0.1:2379/v2/keys/fedora -d value="fun"
188+
{"action":"set","node":{"key":"/fedora","value":"fun","modifiedIndex":4,"createdIndex":4}}
189+
$ curl -L http://127.0.0.1:2379/v2/keys/ 2>/dev/null | jq .
190+
{
191+
"action": "get",
192+
"node": {
193+
"dir": true,
194+
"nodes": [
195+
{
196+
"key": "/fedora",
197+
"value": "fun",
198+
"modifiedIndex": 4,
199+
"createdIndex": 4
200+
}
201+
]
202+
}
203+
}
204+
----
205+
Looks like everything is working!
206+
207+
== Updates!
208+
209+
So far we’ve been disabling one of the best features of Fedora CoreOS: automatic updates.
210+
Let’s see them in action.
211+
212+
We can do this by removing the `zincati` config that is disabling the updates and restarting the zincati service:
213+
214+
[source,bash]
215+
----
216+
$ sudo rm /etc/zincati/config.d/90-disable-auto-updates.toml
217+
$ sudo systemctl restart zincati.service
218+
Connection to 192.168.122.163 closed.
219+
----
220+
221+
After restarting `zincati.service` the machine will reboot after a short period of time.
222+
In this case the update has been staged and the system rebooted in order to boot into the new deployment with the latest software.
223+
224+
When we log back in we can view the current version of Fedora CoreOS is now `31.20200113.3.1`.
225+
The rpm-ostree status output will also how the older version, which still exists in case we need to rollback:
226+
227+
[source,bash]
228+
----
229+
$ rpm-ostree status
230+
State: idle
231+
AutomaticUpdates: disabled
232+
Deployments:
233+
● ostree://fedora:fedora/x86_64/coreos/stable
234+
Version: 31.20200113.3.1 (2020-01-14T00:20:15Z)
235+
Commit: f480038412cba26ab010d2cd5a09ddec736204a6e9faa8370edaa943cf33c932
236+
GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4
237+
238+
ostree://fedora:fedora/x86_64/coreos/stable
239+
Version: 31.20200108.3.0 (2020-01-09T21:51:07Z)
240+
Commit: 113aa27efe1bbcf6324af7423f64ef7deb0acbf21b928faec84bf66a60a5c933
241+
GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4
242+
----
243+
244+
*NOTE:* The currently booted deployment is denoted by the `●` character.
245+
246+
You can view the differences between the two versions by running an `rpm-ostree db diff` command:
247+
248+
[source,bash]
249+
----
250+
$ rpm-ostree db diff 113aa27efe1bbcf6324af7423f64ef7deb0acbf21b928faec84bf66a60a5c933 f480038412cba26ab010d2cd5a09ddec736204a6e9faa8370edaa943cf33c932
251+
ostree diff commit from: 113aa27efe1bbcf6324af7423f64ef7deb0acbf21b928faec84bf66a60a5c933
252+
ostree diff commit to: f480038412cba26ab010d2cd5a09ddec736204a6e9faa8370edaa943cf33c932
253+
Upgraded:
254+
bind-libs 32:9.11.13-3.fc31 -> 32:9.11.14-2.fc31
255+
...
256+
----
257+
258+
If the system is not functioning fully for whatever reason we can go back to the previous version:
259+
260+
[source,bash]
261+
----
262+
$ sudo rpm-ostree rollback --reboot
263+
----
264+
265+
After logging back in after reboot we can see we are now booted back into the old `31.20200108.3.0` deployment from before the upgrade occurred:
266+
267+
[source,bash]
268+
----
269+
$ rpm-ostree status
270+
State: idle
271+
AutomaticUpdates: disabled
272+
Deployments:
273+
● ostree://fedora:fedora/x86_64/coreos/stable
274+
Version: 31.20200108.3.0 (2020-01-09T21:51:07Z)
275+
Commit: 113aa27efe1bbcf6324af7423f64ef7deb0acbf21b928faec84bf66a60a5c933
276+
GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4
277+
278+
ostree://fedora:fedora/x86_64/coreos/stable
279+
Version: 31.20200113.3.1 (2020-01-14T00:20:15Z)
280+
Commit: f480038412cba26ab010d2cd5a09ddec736204a6e9faa8370edaa943cf33c932
281+
GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4
282+
283+
----
284+
285+
== Conclusion
286+
287+
In these tutorials we’ve learned a little bit about Fedora CoreOS.
288+
We’ve learned how it’s delivered as a pre-created disk image, how it’s provisioned in an automated fashion via Ignition, and also how automated updates are configured and achieved via zincati and RPM-OSTree.
289+
The next step is to try out Fedora CoreOS for your own use cases and https://github.com/coreos/fedora-coreos-tracker/blob/master/README.md#communication-channels-for-fedora-coreos[join the community]!

0 commit comments

Comments
 (0)