🇵🇱->🇬🇧 Go to english version of this post / Przejdź do angielskiej wersji tego wpisu
Mój wpis o darmowym serwerze VPS od Oracle jest prawdziwym hitem tego bloga. Patrząc na statystyki ma więcej odsłon niż wszystkie inne wpisy razem wzięte. Nic w tym dziwnego, gdyż chyba każdy lubi czasem trochę przycebulić i dostać coś fajnego za darmo. Oczywiście będą tutaj głosy mówiące, że jak coś jest za darmo to towarem jesteśmy tak naprawdę my, a może raczej nasze dane. Pewnie tak, ale przyznam szczerze, że ja osobiście nie zastanawiałem się dwa razy decydując się na skorzystanie z tej ciekawej promocji Oracle, w której można otrzymać tak naprawdę trzy serwery – jeden z 4-rdzeniowym procesorem o 24GB RAMu oparty o architekturę ARM, oraz dwa o znacznie słabszej mocy procesora (1/8 OCPU) i tylko 1GB RAM oparte na architekturze AMD. Ten pierwszy to prawdziwa kobyła, na której można zrobić naprawdę wiele kozackich rzeczy, a dwa pozostałe to takie satelity, które świetnie sprawdzają się jako poligony treningowe lub dla mniejszych projektów. Co ciekawe w zeszłym tygodniu orałem moją całą infrastrukturę Oracle i stawiałem od zupełnego zera, co dało mi możliwość sprawdzenia czy opisany przeze mnie sposób dalej działa i muszę z przyjemnością powiedzieć, że tak. Zatem oficjalnie odpowiadam na wiele zadanych mi w ostatnich miesiącach pytań – tak, serwery w ramach Always Free Tier są dalej normalnie dostępne, a mój poradnik aktualny.
Co ciekawego zrobimy dzisiaj?
W dzisiejszym wpisie na tym darmowym VPS od Oracle postawimy prywatną chmurę na pliki, na której będziemy mogli przechowywać do blisko 200 GB danych. Zrobimy to poprzez uruchomienie kontenera Docker, w którego środku będzie Nextcloud, a zrobimy to przy użyciu Portainer. Do tego podepniemy do niego własną domenę, do czego wykorzystamy NGINX Proxy Manager, który będzie uruchomiony jako oddzielny kontener, oraz Cloudflare (choć dla chętnych, a raczej niechętnych do CF, opiszę również jak to zrobić przez FreeDNS::24). Oczywiście zadbamy także o szyfrowanie komunikacji, czyli SSL/HTTPS, co zrealizujemy również przez NGINX Proxy Manager używając certyfikatu Let’s Encrypt.
Spis treści
- Pozyskanie darmowego serwera VPS od Oracle
- Wstępna konfiguracja serwera
- Zapora sieciowa
- Docker i Portainer
- Podpięcie domeny przez Cloudflare
- Alternatywne rozwiązanie z FreeDNS::42 zamiast Cloudflare
- NGINX Proxy Manager
- Nextcloud i MariaDB
- Zamykanie portów (aktualizacja 07-10-2024)
Pozyskanie darmowego serwera VPS od Oracle
Jeżeli nie masz jeszcze takiego serwera to cały proces opisałem naprawdę bardzo szczegółowo w oddzielnym wpisie. Na potrzeby tego poradnika proponuję utworzyć sobie instancję o następujących parametrach:
- domena – EU-Frankfurt-1 (ja ostatnio nie miałem problemów z uzyskaniem VPS dokładnie z domeny AD2),
- Shape (typ maszyny) – zakładka Virtual Machine i dalej Ampere, gdzie wybieramy konkretnie VM.Standard.A1.Flex,
- Image (obraz systemu) – Ubuntu 22.04, które zaktualizujemy do 24.04 LTS podczas początkowej konfiguracji, bo z niewiadomych mi przyczyn Oracle podaje, że 24.04 LTS nie działa z tym typem maszyny na ARM (co jest nieprawdą i udowodnię to) i po prostu nie pozwala od razu zacząć od tego systemu,
- CPU – 4 rdzenie,
- RAM – 24GB, na potrzeby Nextcloud nie potrzebujemy aż tyle, ale nie ograniczajmy się i bierzmy maksymalną ilość, którą dają, bo w przyszłości pozwoli nam to na uruchomienie również innych rzeczy,
- publiczny adres IPv4 – pamiętaj, aby przypisać go do maszyny już podczas jej tworzenia co uprości cały proces, rozważ także przypisanie adresu IPv6, bo może Ci się przydać w przyszłości,
- klucze SSH – Oracle nie da Ci bez tego ruszyć dalej, co jest dobrą praktyką, więc po prostu zrób nowy klucz i go zapisz lub skorzystać ze swojego i podaj go Oracle,
- pojemność dysku – (określa się to w sekcji Boot volume po zaznaczeniu Specify a custom boot volume size) – za darmo możemy dostać maksymalnie 200GB do podziału na wszystkie maszyny, możesz przypisać wszystko do tej maszyny ARM albo podzielić to jakoś, tak aby również dla tych dwóch AMD coś zostało,
- szyfrowanie komunikacji pomiędzy instancją i magazynem – zaznacz opcję Use in-transit encryption.
Wstępna konfiguracja serwera
Zaczynamy standardowo o połączenia się z wcześniej utworzoną instancją. Ja przeważnie używam do tego celu aplikacji Termius, ale możesz też użyć PuTTY lub dowolnego innego sposobu pozwalającego na nawiązanie komunikacji SSH. To jak łączyć się z serwerami poprzez SSH opisałem w tym wpisie. Natomiast w tym wpisie to jak używać kluczy SSH. Nie będę tego wszystkie powtarzał jeszcze raz. Skupimy się tutaj jedynie na tym co dla konkretnego przypadku jest nieoczywiste. Do połączenia przez SSH potrzebujemy w zasadzie czterech rzeczy:
- Adresu IP serwera
- Nazwy użytkownika, na którego się zalogujemy
- Publicznego klucza SSH
- Prywatnego klucza SSH
Pierwsza dwa uzyskamy poprzez wejście do centrum zarządzania instancjami Oracle. Po poprawnym jej utworzeniu powinniśmy w tym miejscu widzieć ją na liście naszych instancji, więc wejdźmy do jej właściwości [1].
Szukane przez nas informacje (adres IP serwera [2] i nazwa użytkownika [3]) znajdują się w zakładce Instance information w sekcji Instance access po prawej stronie.
Wymagane do uwierzytelniania klucze SSH pobraliśmy już na dysk podczas tworzenia instancji. Mamy już wszystko, więc teraz trzeba tylko to wszystko wrzucić do Termius’a (lub użyć innego programu) i połączyć się z naszym nowiusieńkim VPSem.
Teraz przeprowadzimy podstawową konfigurację serwera. Zaczniemy oczywiście od aktualizacji pakietów. Po jej zakończonej można rozważyć restart serwera.
sudo apt update
sudo apt upgrade -y
sudo reboot now
Z oczywistych przyczyn zostaniem rozłączeni z serwerem, poczekajmy chwilę na jego ponowne uruchomienie i wznówmy połączenie SSH. Teraz przystąpimy to aktualizacji systemu Ubuntu z wersji 22.04 do 24.04 LTS.
sudo do-release-upgrade
Cały proces jest intuicyjny, więc nie będę go szczegółowo opisywał w tym miejscu. Może kiedyś zrobię o tym oddzielny wpis, jeżeli faktycznie okaże się, że w narodzie jest taka potrzeba. Jeżeli potrzebujesz potwierdzenia, że aktualizacja przebiegła pomyślnie to możesz użyć komendy:
lsb_release -a
Wynik działania polecenia powinien wyglądać mniej więcej tak:
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 24.04.1 LTS
Release: 24.04
Codename: noble
W ramach podstawowej konfiguracji zawsze sprawdzam jeszcze ustawienia autoryzacji poprzez SSH, bo przeważnie nie jest to ustawione tak jak lubię. Dlatego wchodzimy do edytora tekstu i zmieniamy zapisy w pliku sshd_config.
sudo nano /etc/ssh/sshd_config
Musimy w nim znaleźć odpowiednie wiersze i zmienić ich wartość na te poniżej. Uwaga, wskazane linie mogą nie tylko nie być jedna pod drugą, ale także występować w innej kolejności.
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
Zapora sieciowa
Ja korzystając z Oracle używam tak naprawdę trzypoziomowej zapory. Pierwszym poziomem jest zapora w samej infrastrukturze Oracle. Druga to iptables na serwerze, a trzecia to pakiet ufw, który doinstalowuję zawsze we własnym zakresie. Skonfigurujmy je jedna po drugiej.
To jak otwierać porty w infrastrukturze Oracle opisałem w tym wpisie. W turbo skrócie robi się to wchodząc w Virtual Cloud Networks (pamiętam, aby najpierw wybrać odpowiedni Compartment) -> na liście znajdujemy naszą sieć i wchodzimy do jej właściwości -> z menu Resources po lewej wybieramy Security Lists -> na liście powinna być tylko jedna nazwana Default Security List for…. Interesują nas w tym miejscu Ingress Rules i korzystając z przycisku Add Ingress Rules dodajemy reguły otwierające porty 80, 443, 81, 444, 9443. Robimy to wypełniając formularz dla każdego z portów analogicznie do poniższego, w którym zademonstrowałem jak zrobić to dla portu 80.
W ten sposób otworzyliśmy następujące porty:
- 80 – standardowy HTTP dla NGINX Proxy Manager,
- 443 – standardowy HTTPS dla NGINX Proxy Manager,
- 81 – port HTTP dla panelu administracyjnego NGINX Proxy Manager,
- 444 – port HTTPS dla Nextcloud,
- 9443 – port HTTPS dla Portainer.
To wszystko co należy zrobić po stronie Oracle. Kolejnym krokiem jest aktualizacja iptables na serwerze. Jest to taka wewnętrzna tablica z regułami sieciowymi, która określa jaki ruch z i do serwera jest dozwolony, a jaki nie. Przechodzimy na serwer i korzystamy z następujących komend:
sudo su
nano /etc/iptables/rules.v4
W ten sposób otworzy nam się edytor tekstu. Odszukujemy wiersz:
(...)
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
(...)
Zaraz po nim dodajemy nowe wiersze o następującej treści:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 81 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 444 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 9443 -j ACCEPT
Plik rules.v4 zapisujemy i zamykamy poprzez użycie “control + x”, “y” i ENTER. Zostało nam jeszcze skonfigurowanie ostatniej bramy, czyli aplikacji ufw.
sudo apt install ufw
sudo ufw disable
sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22
sudo ufw allow 80
sudo ufw allow 443
sudo ufw allow 81
sudo ufw allow 444
sudo ufw allow 9443
sudo ufw enable
sudo ufw status verbose
Finalny wynik powinien wyglądać tak:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip
To Action From
-- ------ ----
22 ALLOW IN Anywhere
80 ALLOW IN Anywhere
443 ALLOW IN Anywhere
444 ALLOW IN Anywhere
81 ALLOW IN Anywhere
9443 ALLOW IN Anywhere
22 (v6) ALLOW IN Anywhere (v6)
80 (v6) ALLOW IN Anywhere (v6)
443 (v6) ALLOW IN Anywhere (v6)
444 (v6) ALLOW IN Anywhere (v6)
81 (v6) ALLOW IN Anywhere (v6)
9443 (v6) ALLOW IN Anywhere (v6)
Dla pewności należy jeszcze upewnijmy się, że usługa ufw będzie uruchamiana wraz ze startem systemu (np. po restarcie). Ta opcja powinna się włączyć sama, ale zawsze dobrze sprawdzić to we własnym zakresie. Wchodzimy do pliku konfiguracyjnego ufw:
sudo nano /etc/ufw/ufw.conf
Interesuje nas tutaj, aby zmienna ENABLED była ustawiona na yes:
# Set to yes to start on boot. If setting this remotely, be sure to add a rule
# to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp'
ENABLED=yes
Teraz pozostaje już tylko zrestartować maszynę.
sudo reboot now
Docker i Portainer
Opisałem to szczegółowo w oddzielnym wpisie, więc tutaj przejdę tylko na szybko w ramach przypomnienia.
sudo apt install docker.io -y
sudo groupadd docker
sudo usermod -aG docker $USER
Docker zainstalowany, więc przechodzimy do stworzenia wolumenu na dane Portainer’a.
docker volume create portainer_data
Następnym krokiem jest już utworzenie odpowiednio skonfigurowanego kontenera.
docker run -d \
-p 9443:9443 \
-v /var/run/docker.sock:/var/run/docker.sock \
-v portainer_data:/data \
--name Portainer \
--restart unless-stopped \
portainer/portainer-ce:latest
Portainer został uruchomiony na porcie 9443, więc teraz musimy odszukać jeszcze raz adres serwera, który wykorzystywaliśmy do połączenia SSH, wejść do przeglądarki i w pasek adresu wpisać:
https://<ip_vpsa_oracle>:9443
Naszym oczom ukaże się bardzo prosty instalator, w którym wystarczy ustawić jedynie login i hasło dla administratora. Na następnej stronie wybieramy przycisk Get Started jako, że chcemy, aby Portainer używał środowiska znajdującego się na maszynie lokalnej, na której jest uruchomiony. Finalnie zostaniemy przeniesieni do listy dostępnych środowisk, na której będzie jedynie jedno o nazwie local (z ang. lokalne). Aby rozpocząć zarządzanie tym środowiskiem należy po prawej stronie nacisnąć niebieski przycisk Live connect. Poskutkuje to tym, że po lewej stronie zamiast Environment: None selected pojawią się nam zakładki z opcjami do zarządzania.
Podpięcie domeny przez Cloudflare
- Logujemy się na Cloudflare.com i naciskamy przycisk Add a domain.
- Wpisujemy adres posiadanej przez nas domeny, w moim przypadku jest to przykładowe exampleforblog.com. Wybieramy Manually enter DNS records, bo chcemy zaczynać od czystej karty bez zbędnego zgadywania CF jakie rekordy chcemy mieć. Potwierdzamy przyciskiem Continue.
- Na następnej stronie przewijamy na dół, bo plan (oczywiście jedyny słuszny, czyli darmowy), który nas interesuje jest na samym końcu.
- Wybieramy plan Free i potwierdzamy przyciskiem Continue.
- Na kolejnej stronie przewijamy niżej do informacji, które nas interesują.
- W pierwszej kolejności CF prosi nas o wyłączenie funkcji DNSSEC u naszego dostawcy domen. Nie wszyscy dostawcy włączają to z automatu, ale przykładowo takie OVH chyba właśnie tak robi, więc uznałem, że warto o tym wspomnieć.
- Na tej samej stronie, ale niżej, CF listuje nam dwa adresy DNS, do których mamy skierować cały ruch z posiadanej przez nas domeny. Robi się to na stronie dostawcy domeny.
- Z menu po lewej wybieramy zakładkę DNS i następnie Records. Zaczynamy dodawanie rekordów przyciskiem Add record.
- W Type zostawiamy A (tak jak jest domyślnie). W pole Name wpisujemy portainer. W IPv4 address podajemy adres naszego serwera VPS od Oracle, goły adres bez żadnych portów, czyli np. 101.102.103.104 (oczywiście zmyśliłem ten adres, więc tutaj wpisz swój). Chcemy, aby ruch był przepuszczany przez CF, więc zostawiamy ustawienie Proxied. TTL nie da się zmienić, więc zostaje Auto. W polu Comment na dole możemy wpisać dowolny komentarz, który pozwoli nam w przyszłości zorientować się o co chodzi i skąd wziął się ten rekord. Napisz po prostu swoimi słowami to co chcesz i do czego będziesz używać tego rekordu. Na koniec pozostaje tylko potwierdzić przyciskiem Save.
- Pierwszy rekord dodany, ale na potrzeby tego poradnika będziemy potrzebować w sumie trzech, więc dodajemy kolejne korzystając ponownie z przycisku Add record.
- W ten sposób dodajemy jeszcze analogicznie rekordy dla Name – cloud i nginx. To co zrobiliśmy teraz to utworzyliśmy trzy subdomeny dla domeny macierzystej. Są to odpowiednio portainer.exampleforblog.com, cloud.exampleforblog.com i nginx.exampleforblog.com.
- Wracamy do menu po lewej i tym razem wybieramy zakładkę SSL/TLS, a z niej Overview. W sekcji podpisanej SSL/TLS encryption naciskamy przycisk Configure.
- W okienku podpisanym Custom SSL/TLS naciskamy przycisk Select.
- Zmieniamy opcję z Full na Flexible i potwierdzamy wybór przyciskiem Save.
- W ramach tej samej zakładki z menu po lewej wybieramy Edge Certificates. Odnajdujemy okienko podpisane Always Use HTTPS i włączamy tą funkcję.
- Zjeżdżamy niżej, znajdujemy Automatic HTTPS Rewrites i również włączamy tą funkcję.
Gotowe. Możemy się już wylogować z Cloudflare i przejść do następnego kroku.
Alternatywne rozwiązanie z FreeDNS::42 zamiast Cloudflare
To samo co w Cloudflare można uzyskać poprzez skorzystanie np. z FreeDNS::42 lub innego narzędzia tego rodzaju.
- Zaczynamy od zalogowania się do swojego konta na FreeDNS::42. Przychodzimy do Utwórz strefę.
- Jako Nazwa strefy podajemy naszą domenę. Jako Typ strefy wybieramy Podstawowe. Naciskamy przycisk Utwórz.
- Nowa strefa utworzona, więc przechodzimy do zakładki modyfikacji.
- Przewijamy na dół…
- … aż znajdziemy sekcję Rekordy (NS) serwerów DNS. Widnieją w niej dwa adresy fns1.42.pl i fns2.42.pl. Na te adresy DNS mamy skierować cały ruch z posiadanej przez nas domeny. Robi się to na stronie dostawcy domeny.
- Na tej samej stronie przewijamy jeszcze trochę aż do sekcji Rekordy adresów (A), gdzie dodajemy trzy rekordy, które w kolumnie Nazwa będą miały wartości kolejno portainer, nginx i cloud, natomiast w kolumnie IP podajemy trzy razy adres naszego serwera VPS od Oracle.
- Taką konfigurację finalizujemy przyciskiem Utwórz konfigurację strefy, który znajduje się na samym dole.
- Na koniec zostanie nam wyświetlone podsumowanie, na którym możemy sprawdzić czy wszystko się zgadza.
NGINX Proxy Manager
NGINX Proxy Manager posłuży do odpowiedniego kierowania ruchem trafiającym do naszego serwera za pośrednictwem domeny, którą dodaliśmy przed chwilą w Cloudflare/FreeDNS::42. Chodzi o to, żeby np. ruch z subdomeny portainer.exampleforblog.com trafił dokładnie na port 9443, czyli tam gdzie uruchomiony jest panel administratora Portainer’a. NGINX Proxy Manager to dużym uproszczeniu taki drogowskaz.
Uruchomienie kontenera z NGINX Proxy Manager’em rozpoczynamy od zalogowania się do panelu administratora Portainer. W sekcji Environments wybieramy local i naciskamy przycisk Live connect. Z menu po lewej wybieramy Stacks. Naciskamy przycisk Add stack. W polu Name wpisujemy nginx_proxy_manager. W sekcji Build method zostawiamy domyślne Web editor. W obszar tekstowy Web editor wklejamy ten gotowy kod:
version: '3.8'
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: unless-stopped
ports:
- '80:80' # Public HTTP Port
- '443:443' # Public HTTPS Port
- '81:81' # Admin Web Port
volumes:
- /var/lib/docker/volumes/nginx_proxy_manager/data:/data
- /var/lib/docker/volumes/nginx_proxy_manager/letsencrypt:/etc/letsencrypt
Pokrótce go skomentuję. Korzystamy z obrazu jc21/nginx-proxy-manager, który zostanie pobrany z Docker Hub. Kontener będzie automatycznie restartowany po każdym zatrzymaniu, chyba że sami ręcznie go zatrzymamy. Będzie używać portów 80 (HTTP), 443 (HTTPS) i 81. Pod tym ostatnim dostępny będzie panel administratora. To właśnie na niego wskażemy subdomeną nginx.exampleforblog.com. Tworzymy dwa wolumeny, którymi wyciągniemy z kontenera foldery /data (dane dot. konfiguracji) i /etc/letsencrypt, czyli miejsce, w którym zapisane będą certyfikaty SSL.
Po wklejeniu tego kodu niewiele więcej musimy robić, bo wystarczy tylko utworzyć tak skonfigurowany kontener korzystając z przycisku Deploy the stack znajdującego się w sekcji Actions na samym dole. Robienie tego z poziomu Stacks ma tą zaletę, że za jednym razem załatwiamy wszystko, czyli tworzymy kontener oraz wolumeny potrzebne do jego działania.
Przejdźmy teraz do panelu administratora NGINX Proxy Manager’a. Wchodzi się tam przez przeglądarkę wpisując w pasek adresu:
https://<ip_vpsa_oracle>:81
Przywita nas od razu formularz logowania. Ale jaki jest login i hasło? Na pomoc przychodzi nam dokumentacja, w której podane jest, że kontener tworzony jest z domyślnymi poświadczeniami, które po pierwszym logowaniu jesteśmy zmuszeni zmienić. Są to:
Email: admin@example.com
Password: changeme
Logujemy się przy ich pomocy i od razu tworzymy nowego administratora na podstawie już wprowadzonych przez siebie danych. Przechodzimy do zakładki Hosts, która znajduje się na pasku na górze, i wybieramy Proxy Hosts. Korzystając z przycisku Add Proxy Host dodajemy pierwszego. W pole Domain Names wpisujemy portainer.exampleforblog.com (oczywiście exampleforblog.com zamień na swoją domenę). W Scheme wybieramy https. W Forward Hostname / IP wpisujemy lokalny adres IP swojego serwera. Aby go poznać potrzebujemy zainstalować net-tools:
sudo apt install net-tools
I użyć polecenia:
ifconfig
Poszukiwany adres będzie znajdował się w sekcji enp0s6. Tak wygląda wycinek z wyniku działania komendy ifconfig.
enp0s6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
inet 10.0.0.195 netmask 255.255.255.0 broadcast 10.0.0.255
inet6 ... prefixlen 128 scopeid 0x0<global>
inet6 ... prefixlen 64 scopeid 0x20<link>
ether 02:00:17:06:21:40 txqueuelen 1000 (Ethernet)
RX packets 335922 bytes 763693420 (763.6 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 301753 bytes 418933520 (418.9 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Adres, którego szukamy to w moim przypadku 10.0.0.195 (u Ciebie prawie na pewno będzie inny). Pozostaje nam jeszcze wpisać 9443 w polu Forward Port. Prawidłowo wypełniony formularz w moim wypadku wygląda tak:
Ale to nie koniec, bo musimy jeszcze przeskoczyć z zakładki Details do SSL, gdzie z menu rozwijanego podpisanego SSL Certificate wybieramy Request a new SSL Certificate. Do tego zaznaczamy opcję Force SSL oraz I Agree to the Let’s Encrypt Terms of Service.
Teraz możemy już potwierdzić przyciskiem Save. Robimy to samo analogicznie jeszcze dwa razy dla dwóch pozostałych subdomen, które utworzyliśmy w Cloudflare.
- dla nginx.exampleforblog.com podajemy port 81
- dla cloud.exampleforblog.com podajemy port 444
Nextcloud i MariaDB
Ostatnie co nam pozostało to stworzenie kontenera Nextcloud, dla którego bazą danych będzie MariaDB uruchomiona w oddzielnym, ale sprzężonym kontenerze. Zrobimy to w sposób analogiczny do tego jak robiliśmy to w przypadku NGINX Proxy Manager, czyli poprzez Stacks w Portainer. A zatem wchodzimy w Stacks i naciskamy przycisk Add stack. Jako Name podajemy nextcloud, a w Web editor wklejamy poniższy gotowy kod:
version: '2'
services:
db:
image: mariadb:latest
restart: unless-stopped
command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
volumes:
- /var/lib/docker/volumes/Nextcloud_Database:/var/lib/mysql
environment:
- MYSQL_ROOT_PASSWORD=<hasło_roota_bazy_danych>
- MYSQL_PASSWORD=<hasło_użytkownika_dla_nextcloud>
- MYSQL_DATABASE=nextcloud
- MYSQL_USER=nextcloud
app:
image: lscr.io/linuxserver/nextcloud:latest
restart: unless-stopped
ports:
- 444:443
links:
- db
volumes:
- /var/lib/docker/volumes/Nextcloud_Application/config:/config
- /var/lib/docker/volumes/Nextcloud_Application/data:/data
environment:
- MYSQL_PASSWORD=<hasło_użytkownika_dla_nextcloud>
- MYSQL_DATABASE=nextcloud
- MYSQL_USER=nextcloud
- MYSQL_HOST=db
- PUID=1000
- PGID=1000
- TZ=Europe/Warsaw
W tym kodzie tworzymy tak naprawdę tandem składający się z dwóch kontenerów. Pierwszy z nich to baza danych. Z kolei drugi to nasza chmura Nextcloud. Co ciekawe dla bazy danych nie przypisałem żadnego portu, a mogłem, bo w przyszłości mógłbym chcieć z niej skorzystać. Nie jest to wielki problem, bo w później można to zmodyfikować. Natomiast dla Nextcloud przypisałem port 444, bo 443 jest już zajęty do obsługi NGINX Proxy Manager’a, ale to zostało już przez nas załatwione odpowiednim przekierowaniem na etapie konfiguracji NGINX Proxy Manager’a. Jeżeli chodzi o obraz Dockera to wykorzystałem lscr.io/linuxserver/nextcloud, a nie oficjalny obraz, który też jest dostępny na Docker Hub. Wszystko rozchodzi się o to, że obraz od linuxserver (chyba) jako pierwszy miał wsparcie dla architektury ARM i po prostu używam go już od dawna. Do tego mam średnie doświadczenia z tym oficjalnym, więc po prostu wolę ten i polecam go. Zauważ, że w kodzie są dwa fragmenty <hasło_roota_bazy_danych> i <hasło_użytkownika_dla_nextcloud>, wpisz w ich miejsce wymyślone przez siebie hasła. Tak sparametryzowany Stack tworzymy potwierdzając przyciskiem Deploy the stack i gotowe.
Aby dostać się do naszej świeżo stworzonej chmury nie musimy już bawić się w żadne adresy IP, bo wystarczy, że po prostu wklepiemy w pasek przeglądarki adres cloud.exampleforblog.com. Pozostaje nam już tylko utworzenie konta administratora i finalizacja instalacji. Podczas instalacji może wyniknąć konieczność podania jeszcze raz danych dostępowych do bazy danych MariaDB, bo z nieznanych mi powodów co jakiś czas zdarza się, że nie są one prawidłowo zapisane w kontenerze podczas jego tworzenia. Nie jest to wielki problem, bo wystarczy podczas instalacji Nextcloud rozwinąć menu z ustawieniami zaawansowanymi, wybrać MariaDB i wypełnić cztery pola danymi, które podaliśmy podczas tworzenia Stack’a w Web editor’ze.
MYSQL_PASSWORD=<hasło_użytkownika_dla_nextcloud>
MYSQL_DATABASE=nextcloud
MYSQL_USER=nextcloud
MYSQL_HOST=db
O Nextcloud pisałem sporo w dwóch wpisach, więc podlinkuję je tutaj, bo mogą się przydać:
Na koniec jeszcze jedna rzecz, z którą każdy zapewne będzie miał problem, a jest nią taki komunikat:
Rozwiązanie tego problemu jest stosunkowo proste, ale znalezienie go już nie do końca, bo trzeba trochę poszukać w dokumentacji. Mogli to zrobić zdecydowanie bardziej intuicyjnie… Na szczęście macie mnie, czyli gościa, który odwalił już całą robotę i za chwile przedstawi gotowe i zwięzłe rozwiązanie. Otwieramy w edytorze tekstowym plik config.php, o którym mowa w komunikacie.
sudo su
nano /var/lib/docker/volumes/Nextcloud_Application/config/www/nextcloud/config/config.php
Odnajdujemy w nim sekcję trusted_domains i wypełniamy ją analogicznie do tego:
(...)
'trusted_domains' =>
array (
0 => 'localhost',
1 => 'cloud.exampleforblog.com',
),
(...)
Oczywiście zamiast cloud.exampleforblog.com należy podać swoją subdomenę, którą konfigurowaliśmy wcześniej. Teraz odśwież stronę w przeglądarce, a dostęp będzie już możliwy.
Zamykanie portów (aktualizacja 07-10-2024)
Na koniec możemy jeszcze pozamykać porty 81, 444 i 9443 na poziomie zapory Oracle i iptables. Nie jest to jakieś konieczne zabezpieczenie, ale na pewno można nazwać to dobrą praktyką. Usuwa się je analogicznie tak jak je się dodawało, więc nie będę tego opisywał. Dopowiem jednak, że takie działanie sprawi, że Portainer, NGINX Proxy Manager i Nextcloud będą dalej dostępne z zewnątrz, ale jedynie przez odpowiednie subdomeny, które do nich przypisaliśmy w NGINX Proxy Manager’ze. Nie będzie natomiast możliwe dostanie się do np. Portainer’a poprzez wpisanie https://<ip_vpsa_oracle>:9443. Porty muszą jednak zostać otwarte na poziomie ufw, bo jak tam je zamkniemy to nawet i przez NGINX nie będzie możliwości dostępu do zasobu z zewnątrz.
Podsumowanie
Znowu wyszedł mi straszny tasiemiec, ale wierzę, że to lubicie. W tym wpisie zawarty jest kawał porządnego mięska. Liczę, że komuś się to przyda. Jeżeli Tobie się przydało to napisz do mnie w dowolny możliwy sposób (komentarz poniżej, Mastodon itd.) i pochwal się swoją nową i co najważniejsze w pełni darmową chmurą. Poleć ten sposób znajomym, niech i oni na tym skorzystają. W przypadku napotkania jakichkolwiek problemów także śmiało pisz. Obiecuję, że postaram się pomóc najlepiej jak tylko będę mógł. Powodzenia!
Aha i na koniec, zauważ, że tak stworzone środowisko jest w zasadzie idealną podwaliną do tego, żeby na tym serwerze stawiać różne inne wartościowe usługi. Myślę, że wrócę do tego tematu jeszcze nie raz w kolejnych wpisach. Jak masz jakiś ciekawy pomysł jak można wykorzystać taką maszynę to chętnie o nim przeczytam!
Pingback: ~200GB Free Cloud for Your files [ENG 🇬🇧] – Tomasz Dunia Blog
Kierunkowy74
@to3k aha, podłączenie domeny do CF lub FreeDNS42 wymaga wpierw jej posiadania…
(ale domena na .eu.org powinna chyba być OK)
Tomasz Dunia
Pewnie, nikt nie mówi, że to musi być płatna domena 😉 Dopóki masz możliwość zmiany DNS dla tej domeny to każda się nada 😉
SpeX
Swego czasu był problem z dodawaniem subdomen .eu.org, nie wiem jak jest teraz w CF.
Tomasz Dunia
To odpuść CF i zrób to przez FreeDNS::42 😉
luq
warto dodać, że Oracle kasuje konta pod różnymi pretekstami – dlatego przechowywanie jakiś ważnych projektów nie wchodzi w grę.
Tomasz Dunia
To nie jest do końca prawda. Oracle ma dość jasną politykę kasowania instancji. Ci co krzyczą w necie, że im skasowano VPS najpewniej robili niedozwolone rzeczy, czyli np. pobierali torrenty lub korzystali z serwera jako VPNa do ściągania torrentów. Plus serwer musi wykazywać oznaki używania, bo te co są w idle cały czas, czyli procesor na 0%, są faktycznie kasowane, żeby udostępnić je innym. Ja mam VPSy na Oracle już od dwóch lat i nikt mi niczego nie usunął.
Grzegorz Cichocki
@to3k
Mam wrażenie, że za mocna ta chmura jak na darmową🤔 , podobna instancja u konkurencji kosztowałaby krocie.
Takie pytania mam:
– Czemu po konfiguracji całości utrzymujesz otwarte porty 81, 444 i 9443 na chmurze?
– Dlaczego korzystasz i z ufw, i z iptables jednocześnie?
Tomasz Dunia
Dla mnie też jest zastanawiające jakim cudem im się opłaca takie coś udostępniać… Robią to, więc korzystam, ale cały czas się nad tym zastanawiam.
Co do nie zamknięcia portów to masz rację zapomniałem o tym napisać, że po wszystkim można pozamykać, bo NGINX rozprowadzi ruch przy otwartych jedynie portach 80 i 443, a nawet w zasadzie samego 443. Dopiszę to.
Co do ufw i iptables, cóż, wolę zarządzać przez ufw, a iptables jest domyślnie w tym serwerze, więc po prostu używam obu.
Ja
Oracle kasuje co chwila takie instancje (mi i wielu innym ludziom usunięto je nie generując w zasadzie żadnego ruchu czy obciążenia serwerów), nie warto marnować czasu na te g…. z Oracle, lepiej wydać kilka zł i mieć jakąś gwarancję, bo tutaj nie masz nic, dziś Ci działa, jutro nie.
Właśnie przez takie akcje zniechęciło mnie Oracle do siebie, jeśli mam coś kupić (służbowo i prywatnie) to omijam Oracle jeśli mogę.
Tomasz Dunia
“nie generując żadnego ruchu”, właśnie dlatego została usunięta. Oracle ma jasno napisane w regulaminie, że usuwa maszyny, które są cały czas w trybie idle, czyli według nich nieużywane.
TataNieWracaRankiWieczory
Czy można prosić w przyszłości o poradnik jak w prosty sposób aktualizować kontenery. Problemem, z którym się zawsze boryka to fakt, że kontenery szybko się starzeją. Czy jest sposób aby ich aktualizacje zautomatyzowac aby móc skupić się na byciu bardziej tatą roku niż adminem dekady? 🙂
Tomasz Dunia
Mam taki poradnik w planach 🙂 Jednakże zanim go napisze mogę teraz na szybko podpowiedzieć, że fajnym plusem stawiania kontenerów przez Stack jest to, że można łatwo zrobić tzw. rebuild, czyli po prostu postawić jeszcze raz tak samo skonfigurowany kontener, ale podczas uruchomienia pobrany będzie nowy obraz kontenera, bo w pliku konfiguracyjnym podawaliśmy „:latest”, czyli zawsze ma pobierać najnowszy
SpeX
Gdzieś kiedyś trafiłem na kontener WatchTawer (lub coś podobnego), którego celem było monitorowania aktualizacji kontenerów i w razie potrzeby wykonywania tego procesu (tak mi się zdaje).