Magento Open Source 2.4.9 na Ubuntu 26.04 z OpenSearch 3.8.0

Czy ten playbook nadaje się do mojego hosta?

Tak, jeżeli celem jest wydzielona maszyna laboratoryjna z Ubuntu 26.04 x86-64. Test wykonaliśmy na VM z 4 vCPU, 16 GiB RAM i 80 GiB dysku. Playbook instaluje Magento, nginx, PHP-FPM, MySQL i OpenSearch, tworzy lokalną bazę oraz konfiguruje usługę WWW. Nie jest to playbook do doinstalowania Magento obok istniejących stron.

Najważniejszy warunek bezpieczeństwa dotyczy nginx. default_server jest serwerem wirtualnym, który nginx wybiera dla żądań niepasujących do innego vhosta. Playbook ustawia własny default_server, dlatego na hoście współdzielonym mógłby przejąć ruch innych stron. Dla tego labu najbezpieczniejszą drogą powrotu jest snapshot albo usunięcie całej VM, a nie ręczne odwracanie wielu zmian w działającym serwerze.

Co przygotować przed pierwszym uruchomieniem?

1. Przygotowujemy świeżą, wydzieloną VM Ubuntu 26.04 x86-64. Nie używamy serwera z istniejącym nginx, PHP, MySQL ani OpenSearch.
2. Ustalamy nazwę DNS dla VM i sprawdzamy, czy wskazuje jej adres. Magento zapisuje magento_base_url w bazie, dlatego późniejsza zmiana nazwy wymaga świadomej zmiany konfiguracji aplikacji.
3. Na control node, czyli maszynie, z której Ansible łączy się z VM, przygotowujemy Ansible i dostęp SSH do użytkownika mogącego wykonać become. Hasła, tokeny i prywatne klucze pozostają poza inventory.
4. Przed pełnym uruchomieniem zapisujemy snapshot VM albo upewniamy się, że można ją bezpiecznie usunąć i odtworzyć. To jest droga powrotu po nieudanym teście.

Jak przygotować inventory i sprawdzić dostęp SSH?

Poniższe polecenia wykonujemy na control node, nie na VM Magento. Inventory to plik YAML, który łączy nazwę hosta, jego adres SSH oraz zmienne używane przez playbook. Najpierw kopiujemy publiczny wzór do pliku lokalnego; plik inventory/local.yml pozostaje ignorowany przez Git.

git clone https://github.com/sysgroup/linuxlab.git
cd linuxlab/magento-lab
cp inventory/local.example.yml inventory/local.yml
$EDITOR inventory/local.yml

Przykładowy inventory używa zarezerwowanej nazwy i adresu dokumentacyjnego. Zastępujemy je własną, działającą nazwą DNS i adresem VM, zachowując zgodność magento_server_name oraz magento_base_url:

all:
  children:
    magento_lab:
      hosts:
        magento-lab.example.test:
          ansible_host: 192.0.2.10
          ansible_user: ubuntu
          magento_server_name: magento-lab.example.test
          magento_base_url: http://magento-lab.example.test/

ansible_user musi mieć dostęp SSH i możliwość wykonania operacji administracyjnych przez become. Nie wpisujemy do inventory haseł, kluczy prywatnych ani sekretów Magento. Przed zmianą VM sprawdzamy połączenie i składnię:

ansible -i inventory/local.yml magento_lab -m ansible.builtin.ping
ansible-playbook -i inventory/local.yml magento-lab.yml --syntax-check
ansible-playbook -i inventory/local.yml magento-lab.yml --check --diff

Pierwsze polecenie powinno zwrócić pong. --syntax-check sprawdza składnię, a --check --diff pokazuje część planowanych zmian bez ich trwałego wykonania. Nie zastępuje on pełnego testu na świeżej VM: pobieranie pakietów, instalacja Magento i uruchomienie usług wymagają rzeczywistego przebiegu.

Jaki snapshot wersji został sprawdzony?

To jest datowany wynik testu z 24 września 2026 r., a nie obietnica zgodności każdej nowszej łatki. Oficjalna macierz Adobe wskazywała dla Magento/Adobe Commerce 2.4.9 serie Composer 2.10, OpenSearch 3, MySQL 8.4, PHP 8.5 i nginx 1.30. Tabela rozdziela te wymagane serie od konkretnych wersji z VM testowej.

Po provisioningu faktyczne wersje są zapisane w /etc/magento-lab/versions.txt.

Jaką rolę pełni OpenSearch w tym labie?

Magento przechowuje dane sklepu w MySQL, a OpenSearch przygotowuje indeks potrzebny do wyszukiwania katalogu. Dla Magento 2.4.9 instalator dostaje --search-engine=opensearch, więc uruchamiamy pojedynczy węzeł OpenSearch przed setup:install. Heap to część RAM przydzielona JVM, czyli procesowi Java OpenSearch; w tym teście ustawiamy 2g. Playbook ustawia także wymagane przez JVM vm.max_map_count=262144. Szczegóły opisują dokumentacje Adobe oraz OpenSearch dla Debiana/Ubuntu.

API jest związane z 127.0.0.1:9200, a Security plugin wyłączony. Taki układ jest dopuszczalny wyłącznie dla izolowanego testu; wystawienie usługi do sieci wymaga TLS, zaufanego CA i uwierzytelniania zgodnego z dokumentacją Security.

Na 24 września 2026 r. tabela testowanych systemów wymieniała Ubuntu 24.04, nie 26.04. Zestaw przeszedł test funkcjonalny na Ubuntu 26.04, ale nie jest deklarowany jako para certyfikowana przez projekt OpenSearch.

Jak uruchomić playbook?

Gdy test połączenia i podgląd zmian nie pokazują błędów, w tym samym katalogu na control node uruchamiamy pełny przebieg:

ansible-playbook -i inventory/local.yml magento-lab.yml

Publiczny kod jest w katalogu magento-lab repozytorium LinuxLab, w commicie 3b13ec894b27008e6f59df0eef8bc0756384dea4. Playbook tworzy lokalną bazę i konto ograniczone do jednej bazy, przechowuje wygenerowane sekrety poza inventory w katalogu dostępnym tylko dla root oraz korzysta z dostarczonego przez Magento nginx.conf.sample.

Magento jest pobierane z publicznego taga 2.4.9 repozytorium magento/magento2. Playbook weryfikuje commit 755e34dd689021c5165db9d35ecff74f7dc51527 i uruchamia composer install z dołączonym lockfile, a nie composer update. Ta ścieżka nie wymaga repo.magento.com, auth.json, COMPOSER_AUTH ani kluczy Marketplace.

Drugi przebieg nie powinien instalować środowiska od początku. To cecha idempotencji: playbook dąży do opisanego stanu, zamiast wykonywać tę samą zmianę przy każdym uruchomieniu. Jeżeli pierwszy przebieg zatrzyma się po części zmian, nie usuwamy ręcznie losowych plików. Najpierw czytamy błąd, poprawiamy przyczynę, ponawiamy przebieg albo odtwarzamy świeżą VM ze snapshotu.

Po czym poznać, że Magento działa?

Playbook kończy się własnymi kontrolami wersji, schematu bazy, silnika wyszukiwania i odpowiedzi HTTP. W zweryfikowanym snapshotcie pierwszy przebieg Ansible Core 2.21.3 zakończył się ok=82 changed=33 failed=0 po 17 min 22 s, a drugi ok=70 changed=0 failed=0. Liczby są wynikiem tego konkretnego testu, nie uniwersalnym progiem powodzenia.

Po przebiegu wykonujemy na VM Magento jako root niezależne kontrole. Nazwę hosta w nagłówku HTTP zastępujemy wartością magento_server_name z inventory:

systemctl is-active nginx php8.5-fpm mysql opensearch cron
sudo -u magento /srv/magento/bin/magento setup:db:status
sudo -u magento /srv/magento/bin/magento config:show catalog/search/engine
curl -sS -o /dev/null -w '%{http_code}\n' \
  -H 'Host: magento-lab.example.test' http://127.0.0.1/
cat /etc/magento-lab/versions.txt

Usługi powinny być active, kontrola bazy nie powinna zgłaszać oczekujących zmian, konfiguracja wyszukiwania powinna zwrócić opensearch, a żądanie HTTP kod 200. Plik versions.txt pozwala później ustalić faktyczne komponenty laboratoryjnej VM bez ujawniania sekretów.

Które ustawienia nie nadają się do produkcji?

To nie jest konfiguracja produkcyjna: HTTP działa bez TLS, nie ma warstwy cache/proxy ani publicznego wystawienia usług. MySQL i OpenSearch są związane z loopbackiem; OpenSearch działa bez Security plugin. Sekrety pozostają w /etc/magento-lab/secrets/ z prawami 0600. Produkcyjne wdrożenie wymaga osobnego projektu sieci, TLS, uwierzytelniania, cache, backupu i obserwowalności. Nie otwieramy portu OpenSearch tylko po to, aby ominąć problem z konfiguracją aplikacji.

Jak odtworzyć lub zaktualizować lab?

Po nieudanym teście najkrótsza droga powrotu to odtworzenie snapshotu świeżej VM albo jej ponowne utworzenie. Nie używamy tego playbooka jako automatycznego uninstaller'a na serwerze współdzielonym. Przed aktualizacją wydania tworzymy nową VM lub snapshot, aby wynik był porównywalny i odwracalny.

1. Sprawdzamy macierz Adobe dla docelowego wydania Magento.
2. Ustalamy tag GitHub, rozwinięty commit oraz sumy Composer i OpenSearch.
3. Wykonujemy pełną instalację na świeżej VM z composer install i lockfile nowego taga.
4. Potwierdzamy usługi, schemat, silnik wyszukiwania, HTTP i /etc/magento-lab/versions.txt, a dopiero potem aktualizujemy dokumentację snapshotu.