Możesz hostować witrynę internetową w ZimaOS bez modyfikowania własnego stosu webowego systemu operacyjnego: uruchom Apache, Nginx lub inny serwer WWW w izolowanym kontenerze Docker i udostępnij osobny port hosta, na przykład 8080. Dzięki temu konfiguracja witryny pozostaje niezależna od interfejsu zarządzania ZimaOS.
Przykład społeczności pokazuje ten podstawowy schemat, ale jeden szczegół wymaga poprawy: jego plik Dockerfile udostępnia port 10000, ale nie instaluje Webmina. Udostępnienie portu nie tworzy usługi, która nasłuchuje za tym portem.
Użyj kontenera zamiast rekonfigurować samo ZimaOS
ZimaOS już korzysta z usług webowych na potrzeby własnego interfejsu. Zastępowanie lub rekonfigurowanie tych usług hosta stwarza niepotrzebne ryzyko problemów z aktualizacjami i konfliktów portów. Osobny kontener zapewnia witrynie własny system plików, pakiety i porty.
ZimaOS obsługuje niestandardowe aplikacje oparte na Dockerze, a jego aktualna dokumentacja aplikacji Docker Compose rozdziela standardowe ustawienia środowiska uruchomieniowego Compose od metadanych ZimaOS App Store.
Prostszy schemat z Apache
W przypadku statycznej lub podstawowej lokalnej witryny nie musisz najpierw tworzyć pełnego obrazu Ubuntu. Minimalna usługa Compose może zamontować katalog witryny w obrazie Apache:
services:
web:
image: httpd:2.4
restart: unless-stopped
ports:
- "8080:80"
volumes:
- /path/to/www:/usr/local/apache2/htdocs:ro
Następnie otwórz w sieci LAN adres http://SERVER-IP:8080. Użyj trwałego katalogu hosta na pliki witryny. Jeśli potrzebujesz PHP, bazy danych, odwrotnego proxy lub interfejsu administracyjnego, dodaj je jako jawnie zdefiniowane usługi, zamiast zakładać, że udostępniony port je zapewnia.
Dlaczego port 10000 nie oznaczał zainstalowanego Webmina
Forumowy plik Dockerfile instalował Apache i kilka narzędzi, a następnie deklarował EXPOSE 80 443 10000. Deklaracja portu w Dockerze to tylko metadane. Obraz nadal potrzebuje procesu nasłuchującego na porcie 10000. Ponieważ ten plik Dockerfile nie instalował ani nie uruchamiał Webmina, samo opublikowanie -p 10000:10000 nie może utworzyć panelu Webmina.
Dokumentacja publikowania portów Dockera wyjaśnia, że opublikowane porty przekierowują ruch do usługi w kontenerze; nie tworzą samej aplikacji.
Tworzenie lokalne i hosting publiczny to różne poziomy ryzyka
Witryna dostępna wyłącznie w sieci LAN jest stosunkowo prosta. Hosting w publicznym internecie wymaga dodatkowo TLS, DNS, uwierzytelniania, instalowania poprawek, rejestrowania zdarzeń, konfiguracji odwrotnego proxy oraz wystawienia routera i zapory sieciowej. Nie przekierowuj do internetu surowego interfejsu zarządzania, takiego jak Webmin, tylko dlatego, że kontener może udostępnić ten port.
Jeśli celem jest stale działający, samodzielnie hostowany stos, niewielki serwer do samodzielnego hostowania może obsługiwać takie obciążenie, ale bezpieczeństwo publicznego dostępu nadal zależy od architektury oprogramowania i kontroli sieci, a nie od modelu sprzętu.
Podsumowanie
Uruchom witrynę jako osobną usługę Docker i udostępnij port, który nie powoduje konfliktów. Korzystaj z obrazów przeznaczonych do konkretnych zastosowań lub jasno zdefiniowanego stosu Compose, przechowuj dane witryny poza kontenerem, a Webmina, bazy danych lub TLS dodawaj tylko wtedy, gdy faktycznie zainstalujesz i skonfigurujesz te usługi.
