Configurare l’accesso SSH e avviare i container all’avvio

Completa tutti i passaggi descritti nella pagina di configurazione iniziale prima di iniziare questo tutorial. Assicurati di aver creato il file ssh-key.pub seguendo le istruzioni fornite nei prerequisiti per il tutorial. Useremo questa chiave nel file di configurazione Butane che stiamo per scrivere.

In questo tutorial, configureremo l’accesso SSH e avvieremo un container all’avvio. Fedora CoreOS è focalizzato sull’esecuzione di applicazioni/servizi in container, quindi raccomandiamo di provare a eseguire container e di evitare di modificare direttamente l’host. Eseguire container mantenendo un layer host intatto rende gli aggiornamenti automatici più affidabili e consente una separazione delle responsabilità: il team di Fedora CoreOS si occupa del sistema operativo mentre gli operatori/sysadmin degli utenti finali si occupano delle applicazioni.

Come di consueto, configureremo l’autologin alla console, un nome host, la configurazione del pager di systemd, ma faremo anche:

Aggiungi una chiave SSH per l’utente core dal file locale ssh-key.pub.
Aggiungi un servizio systemd (failure.service) che fallisce all’avvio.
Aggiungi un container in esecuzione tramite un file di unità container Quadlet di Podman (quadlet systemd.unit container file).
Questo etcd-member.container verrà quindi associato a un etcd-member.service sul sistema in esecuzione.
Il servizio etcd-member.service avvierà e gestirà il ciclo di vita del container utilizzando podman.

Scrittura della configurazione Butane e conversione in Ignition

In modo analogo a quanto fatto nel secondo scenario di provisioning, scriveremo la seguente configurazione Butane in un file chiamato containers.bu:

Esempio con accesso automatico alla console seriale, chiave SSH e più unità systemd

variant: fcos
version: 1.7.0
passwd:
  users:
    - name: core
      ssh_authorized_keys_local:
        - ssh-key.pub
systemd:
  units:
    - name: serial-getty@ttyS0.service
      dropins:
      - name: autologin-core.conf
        contents: |
          [Service]
          # Override Execstart in main unit
          ExecStart=
          # Add new Execstart with `-` prefix to ignore failure
          ExecStart=-/usr/sbin/agetty --autologin core --noclear %I $TERM
          TTYVTDisallocate=no
storage:
  files:
    - path: /etc/profile.d/systemd-pager.sh
      mode: 0644
      contents:
        inline: |
          # Tell systemd to not use a pager when printing information
          export SYSTEMD_PAGER=cat

        [Install]
        WantedBy=multi-user.target
storage:
  files:
    - path: /etc/hostname
      mode: 0644
      contents:
        inline: |
          tutorial
    - path: /etc/profile.d/systemd-pager.sh
      mode: 0644
      contents:
        inline: |
          # Tell systemd to not use a pager when printing information
          export SYSTEMD_PAGER=cat
    - path: /etc/containers/systemd/etcd-member.container
      mode: 0644
      contents:
        inline: |
          [Unit]
          Description=Run a single node etcd
          After=network-online.target
          Wants=network-online.target

          [Container]
          ContainerName=etcd
          Image=quay.io/coreos/etcd:v3.5.21
          Network=host
          Volume=etcd-data:/etcd-data
          Exec=/usr/local/bin/etcd                                \
              --name node1 --data-dir /etcd-data                  \
              --initial-advertise-peer-urls http://127.0.0.1:2380 \
              --listen-peer-urls http://127.0.0.1:2380            \
              --advertise-client-urls http://127.0.0.1:2379       \
              --listen-client-urls http://127.0.0.1:2379          \
              --initial-cluster node1=http://127.0.0.1:2380

          [Install]
        WantedBy=multi-user.target

Esegui Butane per convertirlo in una configurazione Ignition:

butane --pretty --strict --files-dir=./ user.bu --output user.ign

Ora procediamo con il provisioning:

# Imposta l'etichetta SELinux corretta per consentire l'accesso alla configurazione
chcon --verbose --type svirt_home_t user.ign

# Avvia una macchina virtuale Fedora CoreOS
virt-install --name=fcos --vcpus=2 --ram=2048 --os-variant=fedora-coreos-stable \
    --import --network=bridge=virbr0 --graphics=none \
    --qemu-commandline="-fw_cfg name=opt/com.coreos/config,file=${PWD}/user.ign" \
    --disk="size=20,backing_store=${PWD}/fedora-coreos.qcow2"

Sulla console vedrai:

Fedora CoreOS 38.20230709.3.0
Kernel 6.3.11-200.fc38.x86_64 on an x86_64 (ttyS0)

Chiave host SSH: SHA256:T5V4oXMZ0UJ7WRGzNiUOkggO7p5yojTVBUxa6N3vIoQ (ECDSA)
Chiave host SSH: SHA256:oBAvj2kaKKKK++gnchTbxpp/iphvX6EHr0EynwXZ19c (ED25519)
Chiave host SSH: SHA256:Yg2fdA7GC1eoHtIjawDA+WffTKTuNy5ZhQHUJx5GRHk (RSA)
enp1s0: 192.168.124.119 fe80::9b5c:330d:2020:1c9e
Ignition: eseguito il 03/08/2023 18:17:45 UTC (questo avvio)
Ignition: la configurazione fornita dall'utente è stata applicata
Ignition: scritto il file delle chiavi SSH autorizzate per l'utente: core
tutorial login: core (accesso automatico)

Fedora CoreOS 38.20230709.3.0
[systemd]
Failed Units: 1
  failure.service
[core@tutorial ~]$

Disconnettiti dalla console seriale premendo CTRL + ] e poi utilizza l’indirizzo IP riportato per la NIC dalla console seriale per accedere come utente core via SSH:

$ ssh core@192.168.124.119
L'autenticità dell'host '192.168.124.119 (192.168.124.119)' non può essere stabilita.
L'impronta digitale della chiave ED25519 è SHA256:oBAvj2kaKKKK++gnchTbxpp/iphvX6EHr0EynwXZ19c.
Questa chiave non è conosciuta con altri nomi.
Sei sicuro di voler continuare la connessione (yes/no/[fingerprint])? yes
Attenzione: Aggiunto permanentemente '192.168.124.119' (ED25519) all'elenco dei known hosts.
Fedora CoreOS 38.20230709.3.0
Tracker: https://github.com/coreos/fedora-coreos-tracker
Discussioni: https://discussion.fedoraproject.org/tag/coreos

Last login: Thu Aug  3 18:18:06 2023
[systemd]
Failed Units: 1
  failure.service

Il messaggio Failed Units`proviene dai tool di supporto di console login helper messages. Questo specifico helper ci mostra quando `systemd`ha dei servizi in uno stato di errore (failed). In questo caso abbiamo creato il servizio `failure.service con`ExecStart=/usr/bin/false`, quindi abbiamo intenzionalmente generato un servizio che fallisce sempre allo scopo di illustrare i messaggi dell’helper.

Ora che il sistema è avviato e non ci sono veri e propri errori, possiamo verificare lo stato di etcd-member.service, che è stato generato a partire dal nostro file etcd-member.container.

[core@tutorial ~]$ systemctl status --full etcd-member.service
● etcd-member.service - Run a single node etcd
     Loaded: loaded (/etc/containers/systemd/etcd-member.container; generated)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Thu 2023-08-03 18:17:57 UTC; 2min 24s ago
   Main PID: 1553 (conmon)
      Tasks: 10 (limit: 2238)
     Memory: 86.5M
        CPU: 3.129s
     CGroup: /system.slice/etcd-member.service
             ├─libpod-payload-31af97b0ef902b3b3b3d717bd98947b209701b9585db2129ca53f4b33962415e
             │ └─1555 /usr/local/bin/etcd ...
             └─runtime
               └─1553 /usr/bin/conmon ...

Aug 03 18:17:58 tutorial etcd[1553]: 2023-08-03 18:17:58.745207 I | raft: b71f75320dc06a6c became candidate at term 2
Aug 03 18:17:58 tutorial etcd[1553]: 2023-08-03 18:17:58.745372 I | raft: b71f75320dc06a6c received MsgVoteResp from b71f75320dc06a6c at term 2
Aug 03 18:17:58 tutorial etcd[1553]: 2023-08-03 18:17:58.745499 I | raft: b71f75320dc06a6c became leader at term 2
Aug 03 18:17:58 tutorial etcd[1553]: 2023-08-03 18:17:58.745628 I | raft: raft.node: b71f75320dc06a6c elected leader b71f75320dc06a6c at term 2
Aug 03 18:17:58 tutorial etcd[1553]: 2023-08-03 18:17:58.746402 I | etcdserver: setting up the initial cluster version to 3.3
Aug 03 18:17:58 tutorial etcd[1553]: 2023-08-03 18:17:58.747906 N | etcdserver/membership: set the initial cluster version to 3.3
Aug 03 18:17:58 tutorial etcd[1553]: 2023-08-03 18:17:58.748211 I | etcdserver/api: enabled capabilities for version 3.3
Aug 03 18:17:58 tutorial etcd[1553]: 2023-08-03 18:17:58.748384 I | etcdserver: published {Name:node1 ClientURLs:[http://127.0.0.1:2379]} to cluster 1c45a069f3a1d796
Aug 03 18:17:58 tutorial etcd[1553]: 2023-08-03 18:17:58.748510 I | embed: ready to serve client requests
Aug 03 18:17:58 tutorial etcd[1553]: 2023-08-03 18:17:58.750778 N | embed: serving insecure client requests on 127.0.0.1:2379, this is strongly discouraged!

Possiamo anche ispezionare lo stato del container che è stato eseguito dal servizio systemd:

$ podman ps
CONTAINER ID  IMAGE                                              COMMAND                 CREATED        STATUS            PORTS       NAMES
b64a2753a06c  quay.io/coreos/etcd:v3.5.9                         etcd --name node1 ...  2 minutes ago  Up 2 minutes ago              etcd-member

E possiamo impostare una coppia chiave/valore in etcd. Per ora impostiamo la chiave fedora con il valore fun:

[core@tutorial ~]$ curl -L http://127.0.0.1:2379/v3/kv/put -X POST -d '{"key": "ZmVkb3Jh", "value": "ZnVu"}'
{"header":{"cluster_id":"2037210783374497686","member_id":"13195394291058371180","revision":"4","raft_term":"2"}}
[core@tutorial ~]$ curl -sL http://127.0.0.1:2379/v3/kv/range -X POST -d '{"key": "AA==", "range_end": "AA=="}' | jq
{
  "header": {
    "cluster_id": "2037210783374497686",
    "member_id": "13195394291058371180",
    "revision": "4",
    "raft_term": "2"
  },
  "kvs": [
    {
      "key": "ZmVkb3Jh",
      "create_revision": "2",
      "mod_revision": "4",
      "version": "2",
      "value": "ZnVu"
    }
  ],
  "count": "2"
}

Sembra che tutto stia funzionando!

Pulizia

Puoi quindi spegnere l’istanza. Prima, disconnettiti dalla console seriale premendo CTRL + ] e poi distruggi la macchina:

virsh destroy fcos
virsh undefine --remove-all-storage fcos

Puoi ora procedere con il tutorial successivo.

Want to help? Learn how to contribute to Fedora Docs ›