Deploy aplikacji Javowej na serwer - jak to zrobić profesjonalnie

Cześć,
mamy aplikację w Javie i serwer Linuxowy do którego jest dostęp przez ssh. Obecnie deploy polega na skopiowaniu aplikacji na docelowy host oraz uruchomienia aplikacji poprzez ssh.
Problem zaczyna się wtedy np. gdy chcemy zatrzymać aplikację itd. Ktoś musi znać PID tego procesu (jasne, że można robić pgrep, ale nie o to chodzi tutaj). Pytanie brzmi, jak robić taki deploy "state of the art"? Są na pewno dwie opcje:

1. jako kontener docker - odpada
2. jako usługa systemowa - odpada bo trzeba sudo

Moja rada - nie próbuj robić "state of the art", tylko zacznij najprościej.

Ja bym podniósł aplikację, zapisał pid do pliku i tyle.

java -jar app.jar &
echo $! > app.pid

kill $(cat app.pid)

Jeśli będziesz miał jakieś konkretne problemy z tym podejściem, to wtedy będzie się można zastanowić konkretnie jak je rozwiązać, mając konkretny use-case.

johnny12 napisał(a):

ale nie o to chodzi tutaj

A o co chodzi?

Czemu nie rootless docker lub jakaś alternatywa korzystająca z tego samego rodzaju kontenerów? State of the art to zdecydowanie kontenery, bo wszyscy ich używają. Alternatywnie możesz spróbować systemd tylko to niepotrzebny narzut na naukę.

johnny12 napisał(a):

Cześć,
mamy aplikację w Javie i serwer Linuxowy do którego jest dostęp przez ssh. Obecnie deploy polega na skopiowaniu aplikacji na docelowy host oraz uruchomienia aplikacji poprzez ssh.
Problem zaczyna się wtedy np. gdy chcemy zatrzymać aplikację itd. Ktoś musi znać PID tego procesu (jasne, że można robić pgrep, ale nie o to chodzi tutaj). Pytanie brzmi, jak robić taki deploy "state of the art"? Są na pewno dwie opcje:

1. jako kontener docker - odpada
2. jako usługa systemowa - odpada bo trzeba sudo

alias stopGracefully='kill -15 $(pidof java)'
alias stopHard='kill -9 $(pidof java)'

Co do sudo, to wiesz, że można tak skonfigurować sudo, że masz passwordless sudo magicCommand i sudo działa tylko dla tej wybranej komendy?
Zakładając, że masz użytkownika bolek, to jednorazowo robisz: sudo visudo i wskazujesz co może zrobić (np. systemctl start|stop|status|restart <wybranaUsluga>)

bolek ALL=(ALL) NOPASSWD: /bin/systemctl start mojaUsluga, /bin/systemctl stop mojaUsluga, /bin/systemctl status mojaUsluga, /bin/systemctl restart mojaUsluga

Do tego definiujesz usługę systemową i powinno śmigać.

johnny12 napisał(a):

Cześć,
mamy aplikację w Javie i serwer Linuxowy do którego jest dostęp przez ssh. Obecnie deploy polega na skopiowaniu aplikacji na docelowy host oraz uruchomienia aplikacji poprzez ssh.
Problem zaczyna się wtedy np. gdy chcemy zatrzymać aplikację itd. Ktoś musi znać PID tego procesu (jasne, że można robić pgrep, ale nie o to chodzi tutaj).
Pytanie brzmi, jak robić taki deploy "state of the art"?

Ja to bym zaczął od niewchodzenia z ręki na serwery żeby coś uruchamiać i ubijać, bo ani to state-of-the-art, ani najprościej - ręce sobie urobisz, łatwo o pomyłkę, jak ktoś napsuje to trudno zreprodukować i odgadnąć co się wydarzyło bez grzebania w logach systemowych i szukania winnego.

Od deploymentu na serwer powinien być system CI/CD, a nie człowiek. Człowiek może zapomnieć przetestować i wrzucić popsutą wersję, pomylić coś pod presją czasu, a może też wkurzyć się na firmę i celowo napsuć.

Są na pewno dwie opcje:

Odrzucasz z marszu dwie najbardziej normalne opcje

1. jako kontener docker - odpada

A byłoby spoko, bo mógłbyś prosto podnosić i ubijać aplikację w umiarkowanie izolowanym środowisku. Dlaczego docker odpada?

1. jako usługa systemowa - odpada bo trzeba sudo

To by była najprostsza opcja bez dockera i innych wodotrysków, by postawić serwer jako usługę która ma sama wstawać, restartować się i ewentualnie być wyłączana.

Opcji na obejście trzeba sudo masz kilka:

• Możesz stworzyć sobie service account będący właścicielem tej usługi, i z jego poziomu nią zarządzać, mniej więcej: $ systemctl start --user <service>.service
• Dałoby się poczarować grupami i daniem uprawnień grupie do zarządzania usługą poprzez plik sudoers: https://unix.stackexchange.com/a/736119

Chyba najlepiej byłoby mieć faktycznie taki service account ew. z przydzieloną grupą (by ograniczyć mu uprawnienia do minimum) ale nie dawać ludziom wjazdu, by korzystali z niego bezpośrednio, tylko poprzez deployment job w CI/CD odpowiedzialny za wrzucanie nowej wersji aplikacji. Ewentualnie wyłączenie jej, jeśli to potrzebne.

slsy napisał(a):

Czemu nie rootless docker lub jakaś alternatywa korzystająca z tego samego rodzaju kontenerów? State of the art to zdecydowanie kontenery, bo wszyscy ich używają. Alternatywnie możesz spróbować systemd tylko to niepotrzebny narzut na naukę.

Dobra odpowiedź ze złym uzasadnieniem. To nie "Bo tak robią wszyscy" nie jest powodem, dla którego warto używać kontenerów. Oczywiście wyjaśnienie dlaczego tak jest lepiej, to już pod magisterkę podchodzi, jak nie doktorat, a nie post na forum.