Rozdział 1 · 1.9
Własny cloud-init: automatyczna konfiguracja VPS przy pierwszym uruchomieniu
Dzięki cloud-init mogą Państwo podczas instalacji przekazać plik, który VPS sam wykona przy pierwszym uruchomieniu. Serwer od razu zainstaluje Państwa stałe pakiety, utworzy własnego użytkownika i wykona Państwa polecenia. Przydaje się to, gdy często instalują Państwo system ponownie lub chcą zawsze zaczynać od tej samej bazy. Nie potrzebują Państwo do tego API ani terminala.
Gdzie to wpisać?
- Prosimy otworzyć ekran VPS w sekcji Moje produkty.
- Nowy VPS: widoczny jest blok Instalacja VPS (zob. Instalacja VPS: system operacyjny, hasło i klucz SSH). Ponowna instalacja: prosimy wybrać kartę Zaawansowane i przy Ponowna instalacja kliknąć Zainstaluj ponownie... (zob. Ponowna instalacja lub podłączenie obrazu ISO).
- Prosimy wybrać system operacyjny i jak zwykle wpisać hasło roota oraz ewentualnie klucz SSH.
- Pod kluczem SSH prosimy kliknąć Własny cloud-init. Pole się rozwinie.
- Prosimy wkleić plik do pola.
- Prosimy kliknąć przycisk instalacji, na przykład Zainstaluj Debian 13, a przy ponownej instalacji Usuń wszystko i zainstaluj ponownie.
Hasło roota lub klucz SSH są nadal wymagane, także przy własnym cloud-init. Dzięki nim zawsze mogą się Państwo zalogować, również przez konsolę (zob. Konsola: Państwa VPS w przeglądarce).
Co może zawierać plik?
Pole przyjmuje user-data, czyli plik, który cloud-init odczytuje przy pierwszym uruchomieniu. Pierwszy wiersz określa jego rodzaj:
| Pierwszy wiersz | Co to jest? |
|---|---|
#cloud-config | Ustawienia w YAML: pakiety, użytkownicy, pliki, polecenia. Z tego korzysta się najczęściej. |
#!, na przykład #!/bin/bash | Skrypt. Uruchamia się jeden raz jako root, pod koniec pierwszego startu. |
#cloud-boothook | Skrypt, który uruchamia się bardzo wcześnie podczas startu, przy każdym starcie od nowa. Tylko dla zaawansowanych. |
## template: jinja | Szablon ze zmiennymi cloud-init. W wierszu poniżej znajduje się wtedy #cloud-config lub #!. |
- Maksymalnie 256 KB i wyłącznie tekst (UTF-8).
- W YAML wcięcia robi się spacjami, nigdy tabulatorami.
- Siecią (IPv4 i IPv6) zarządza WebOké. Własny network-config nie jest używany, dlatego prosimy nie umieszczać w pliku ustawień sieci.
Przykład
Ten plik aktualizuje wszystkie pakiety, instaluje htop i fail2ban, tworzy użytkownika anna z Państwa kluczem SSH i uprawnieniami sudo, nadaje serwerowi własną nazwę i ustawia strefę czasową:
#cloud-config
hostname: web1
fqdn: web1.example.com
package_update: true
package_upgrade: true
packages:
- htop
- fail2ban
users:
- default
- name: anna
shell: /bin/bash
sudo: "ALL=(ALL) NOPASSWD:ALL"
ssh_authorized_keys:
- ssh-ed25519 AAAAC3Nza... anna@laptop
runcmd:
- timedatectl set-timezone Europe/Amsterdam
Prosimy zastąpić klucz własnym kluczem publicznym (zob. Tworzenie klucza SSH w systemach Windows, Mac i Linux). Wiersz - default pozostawia domyślnego użytkownika, dzięki czemu hasło roota i klucz SSH z formularza nadal działają. Po pierwszym uruchomieniu logują się Państwo poleceniem ssh anna@203.0.113.10. Jak następnie wyłączyć logowanie jako root i skonfigurować fail2ban, opisujemy w Wyłączanie logowania hasłem i jako root i fail2ban przeciwko próbom odgadnięcia hasła.
Wskazówka: Przykład dotyczy systemów Debian i Ubuntu. W AlmaLinux i Rocky Linux pakiety htop i fail2ban znajdują się w dodatkowym repozytorium EPEL. Tam prosimy pominąć packages i pod runcmd wpisać najpierw dnf install -y epel-release, a następnie dnf install -y htop fail2ban.
Co przekazuje sam WebOké?
WebOké zawsze przekazuje nazwę hosta, hasło roota (wyłącznie jako hash) i Państwa klucz SSH. Państwa plik jest z nimi scalany. Jeśli ustawią Państwo samodzielnie users, password, chpasswd lub ssh_authorized_keys, Państwa wartości mają pierwszeństwo przed tym, co przekazuje WebOké.
Uwaga: Jeśli umieszczą Państwo ssh_authorized_keys lub password na najwyższym poziomie pliku, zastąpią one klucz i hasło z formularza. Prosimy wtedy samodzielnie wpisać klucz, którym chcą się Państwo logować, w przeciwnym razie dostęp będzie możliwy tylko przez konsolę.
Czy się udało?
cloud-init uruchamia się jeden raz, przy pierwszym starcie po instalacji. Czasem trwa to kilka minut dłużej niż sama instalacja, zwłaszcza gdy instalowane są pakiety. Prosimy się zalogować i sprawdzić:
anna@web1:~$ cloud-init status --long
anna@web1:~$ sudo tail -n 30 /var/log/cloud-init-output.log
anna@web1:~$ sudo cloud-init schema --system
cloud-init status --longpokazujestatus: done, gdy wszystko jest gotowe,running, gdy proces nadal trwa, orazerror, gdy coś poszło nie tak, razem z opisem błędu. Poleceniemcloud-init status --waitmożna poczekać, aż proces się zakończy.- W
/var/log/cloud-init-output.logznajdują się wyniki instalacji pakietów, poleceń i skryptów. Więcej szczegółów zawiera/var/log/cloud-init.log. cloud-init schema --systemsprawdza plik pod kątem błędów. Jeśli YAML jest niepoprawny, cloud-init pomija niezrozumiałe fragmenty, a instalacja mimo to się nie kończy błędem.
Coś poszło nie tak? Prosimy poprawić to ręcznie na serwerze albo zmienić plik i zainstalować system ponownie. Ponowna instalacja usuwa jednak wszystkie dane z VPS.
Warto wiedzieć
- Funkcja działa we wszystkich systemach operacyjnych z listy: Ubuntu 24.04 i 26.04, Debian 12 i 13, AlmaLinux 9 i 10 oraz Rocky Linux 9 i 10.
- Plik jest przekazywany w postaci zaszyfrowanej i nie jest zapisywany w historii zadań VPS. Mimo to prosimy nie umieszczać w nim haseł ani innych poufnych danych, które nie są potrzebne.
- Wszystkie możliwości opisuje dokumentacja cloud-init na stronie docs.cloud-init.io.
Uwaga: Za zawartość cloud-init odpowiadają Państwo sami. Dział pomocy technicznej nie sprawdza Państwa pliku i nie pomaga w jego pisaniu ani poprawianiu.
