Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
Cześć, nie wiem co wsadzić do cgrules.conf by mi kontenery z systemd działały na Gentoo z OpenRC.
Przed edycją pliku /etc/cgroup/cgrules.conf i rebootem:
doskanoness@lxc-gentoo ~ $ cat /proc/self/cgroup 15:name=systemd:/ 14:misc:/doskanoness 13:pids:/doskanoness 12:hugetlb:/doskanoness 11:net_prio:/doskanoness 10:perf_event:/doskanoness 9:net_cls:/doskanoness 8:freezer:/doskanoness 7:devices:/doskanoness 6:memory:/doskanoness 5:blkio:/doskanoness 4:cpuacct:/doskanoness 3:cpu:/doskanoness 2:cpuset:/doskanoness 1:name=openrc:/sshd 0::/ssh doskanoness@lxc-gentoo ~ $ cat /etc/cgroup/cgrules.conf # /etc/cgrules.conf #The format of this file is described in cgrules.conf(5) #manual page. # # Example: #<user> <controllers> <destination> #@student cpu,memory usergroup/student/ #peter cpu test1/ #% memory test2/ doskanoness misc,pids,hugetlb,net_prio,perf_event,net_cls,freezer,devices,memory,blkio,cpuacct,cpu,cpuset doskanoness/ # End of file doskanoness@lxc-gentoo ~ $ cat /etc/cgroup/cgred.conf # /etc/sysconfig/cgred.conf - CGroup Rules Engine Daemon configuration file # # The four options listed below (CONFIG_FILE, LOG_FILE, NODAEMON, LOG) are # the only valid ones. Defining anything else in this file will cause the # CGroup Rules Engine program to fail. So, don't do it. # The pathname to the configuration file for CGroup Rules Engine CONFIG_FILE="/etc/cgroup/cgrules.conf" # Uncomment the following line to log to specified file instead of syslog #LOG_FILE="/var/log/cgrulesengd.log" # Uncomment the second line to run CGroup Rules Engine in non-daemon mode NODAEMON="" #NODAEMON="--nodaemon" # Set owner of cgred socket. 'cgexec' tool should have write access there # (either using suid and/or sgid permissions or Linux capabilities). SOCKET_USER="" SOCKET_GROUP="cgred" # Uncomment the second line to disable logging for CGroup Rules Engine # Uncomment the third line to enable more verbose logging. LOG="" #LOG="--nolog" #LOG="-v
Po wykonaniu edycji:
doskanoness@lxc-gentoo ~ $ cat /proc/self/cgroup 15:name=systemd:/ 14:misc:/ 13:pids:/ 12:hugetlb:/ 11:net_prio:/ 10:perf_event:/ 9:net_cls:/ 8:freezer:/ 7:devices:/ 6:memory:/ 5:blkio:/ 4:cpuacct:/ 3:cpu:/ 2:cpuset:/ 1:name=openrc:/sshd 0::/sshd doskanoness@lxc-gentoo ~ $ cat /etc/cgroup/cgrules.conf # /etc/cgrules.conf #The format of this file is described in cgrules.conf(5) #manual page. # # Example: #<user> <controllers> <destination> #@student cpu,memory usergroup/student/ #peter cpu test1/ #% memory test2/ doskanoness name=systemd,name=openrc,misc,pids,hugetlb,net_prio,perf_event,net_cls,freezer,devices,memory,blkio,cpuacct,cpu,cpuset doskanoness/ # End of file doskanoness@lxc-gentoo ~ $ cat /etc/cgroup/cgred.conf # /etc/sysconfig/cgred.conf - CGroup Rules Engine Daemon configuration file # # The four options listed below (CONFIG_FILE, LOG_FILE, NODAEMON, LOG) are # the only valid ones. Defining anything else in this file will cause the # CGroup Rules Engine program to fail. So, don't do it. # The pathname to the configuration file for CGroup Rules Engine CONFIG_FILE="/etc/cgroup/cgrules.conf" # Uncomment the following line to log to specified file instead of syslog #LOG_FILE="/var/log/cgrulesengd.log" # Uncomment the second line to run CGroup Rules Engine in non-daemon mode NODAEMON="" #NODAEMON="--nodaemon" # Set owner of cgred socket. 'cgexec' tool should have write access there # (either using suid and/or sgid permissions or Linux capabilities). SOCKET_USER="" SOCKET_GROUP="cgred" # Uncomment the second line to disable logging for CGroup Rules Engine # Uncomment the third line to enable more verbose logging. LOG="" #LOG="--nolog" #LOG="-v" doskanoness@lxc-gentoo ~ $ sudo cgrules -d ... Adding controller memory Adding controller blkio Adding controller cpuacct Adding controller cpu Adding controller cpuset Warning: cgroup_attach_task_pid failed: 50016 Warning: failed to apply the rule. Error was: 50016 EXEC Event: PID = 2671, tGID = 2671 Scanned proc values are 1000 1000 1000 1000 Scanned proc values are 100 100 100 100 Found matching rule doskanoness for PID: 2671, UID: 1000, GID: 100 Executing rule doskanoness for PID 2671... Will move pid 2671 to cgroup 'doskanoness/' Adding controller name=openrc Adding controller name=systemd Adding controller misc Adding controller pids Adding controller hugetlb Adding controller net_prio Adding controller perf_event Adding controller net_cls Adding controller freezer Adding controller devices Adding controller memory Adding controller blkio Adding controller cpuacct Adding controller cpu Adding controller cpuset Warning: cgroup_attach_task_pid failed: 50016 Warning: failed to apply the rule. Error was: 50016 doskanoness@lxc-gentoo ~ $ echo $$ 2585 doskanoness@lxc-gentoo ~ $ sudo cgclassify -g name=systemd:doskanoness 2585 Error changing group of pid 2585: Success
Pełny output cgrules -d: https://dpaste.com/85P8FTS5S
Ostatnio edytowany przez doskanoness (2022-03-11 21:37:30)
Offline
LXC jeszcze istnieje? Docker go nie pożarł?
Jakim poleceniem uruchamiasz poszczególne kontenery?
OpenRC je uruchamia bezpośrednio, czy może LXD, czy czy jakieś Twoje własne skrypty?
Ostatnio edytowany przez Jacekalex (2022-03-12 11:45:12)
Offline
SOA #1, odpalenie:
init 2
w kontenerze uruchamia coś więcej?
Offline
Jacekalex napisał(-a):
Jakim poleceniem uruchamiasz poszczególne kontenery?
No normalnie lxc-start, lxc-create itd.
Pokaż po prostu swój plik /etc/cgroups/cgrules.conf
Ostatnio edytowany przez doskanoness (2022-03-12 21:08:46)
Offline
doskanoness napisał(-a):
Jacekalex napisał(-a):
Jakim poleceniem uruchamiasz poszczególne kontenery?
No normalnie lxc-start, lxc-create itd.
Pokaż po prostu swój plik /etc/cgroups/cgrules.conf
Offline
Używasz Dockera do kontenerów?
Offline
Dockera? czasami się nim bawię.
Generalnie kontenery olałem sikiem prostym, jeśli już, to KVM i maszyna wirtualna z własnym kernelem.
Daje większe możliwości i znacznie większe bezpieczeństwo niż Docker czy inne kombinacje z chrootem na sterydach.
Offline
Jacekalex napisał(-a):
Generalnie kontenery olałem sikiem prostym, jeśli już, to KVM i maszyna wirtualna z własnym kernelem.
Ciekawe, możesz jakoś więcej o tym powiedzieć :)? Rynek wydaje się iść w stronę konteneryzacji
Jacekalex napisał(-a):
Daje większe możliwości i znacznie większe bezpieczeństwo niż Docker
Jakieś przykłady :D?
Sam od jakiegoś czasu wchodzę w konteneryzację i szczerze mówiąc jestem pozytywnie nastawiony do tej technologii
Offline
urbinek napisał(-a):
Rynek wydaje się iść w stronę konteneryzacji
Rynek to poszedł w stronę cloud czyli kvm za natem i load balancerem, ewentualnie jaili pod aplikacji o kodowej nazwie brainless.
Offline
urbinek napisał(-a):
Jacekalex napisał(-a):
Generalnie kontenery olałem sikiem prostym, jeśli już, to KVM i maszyna wirtualna z własnym kernelem.
Ciekawe, możesz jakoś więcej o tym powiedzieć :)? Rynek wydaje się iść w stronę konteneryzacji
Jacekalex napisał(-a):
Daje większe możliwości i znacznie większe bezpieczeństwo niż Docker
Jakieś przykłady :D?
Sam od jakiegoś czasu wchodzę w konteneryzację i szczerze mówiąc jestem pozytywnie nastawiony do tej technologii
Rynek sobie idzie w stronę minimalnych kosztów i maksymalnego zysku.
Dlatego Docker to jest dla nich dar z nieba, 30% kosztów innych rozwiązań,
a tym samym dużo większy zysk.
Moje obserwacje z Dockera?
Instaluje sobie np obraz Worpdress-nginx, ten się niby uruchamia, ale Nginx nie działa?
Dlaczego?
Mam w kompie Nginxa z
/usr/sbin/nginx cap_net_bind_service=ep
ale bez bitów SUID i SGID.
Tak mam to ustawione w profilu Apparmora.
A ten Nginx z kontenera Dpckera z kontenera nie wstaje bez SUID i SGID,
bo to jest domyślny obraz Debiana.
W KVM każda maszynka ma własne jajo, i czy tam siedzi Debian z AA,
czy Centus albo Andorid z SELinuxem czy OpenBSD, żadnej istotnej interakcji z system gospodarza tutaj nie ma.
To eliminuje też niektóre zagrożenia (oczywiście nie wszystkie).
Oczywiście do KVM nie ma gotowych obrazów zdefiniowanych w plikach composer.json,
dlatego z biznesowego punktu widzenia nie nadają się na szybki i łatwy zysk z konteneryzacji.
Ale prawdziwa wirtualizacja to trochę twardsza bariera niż chroot na sterydach.
Zwłaszcza w kontekście np niedawnego CVE-2022-0847 czy wcześniejszego CVE-2016-5195.
Pozdro
;-)
Ostatnio edytowany przez Jacekalex (2022-03-14 19:45:19)
Offline
mati75 napisał(-a):
Rynek to poszedł w stronę cloud czyli kvm za natem i load balancerem, ewentualnie jaili pod aplikacji o kodowej nazwie brainless.
Który? Afaik cały rynek cloud idzie w stronę konteneryzacji czy usług serverless.
O ile aplikacja nie wymaga mocnego sprzętu (np SAP) to aplikacje pisze się atomicznie aby można było je skonteneryzować i zarządzać k8s czy innym ranczerem.
Jacekalex napisał(-a):
Moje obserwacje z Dockera?
Instaluje sobie np obraz Worpdress-nginx, ten się niby uruchamia, ale Nginx nie działa?
[...]
No rozumiem, ale to jest kwestia do konfigurowania aplikacji. Nie wszystko działa przecież od strzału. Jak dla mnie to normalne.
Jacekalex napisał(-a):
W KVM każda maszynka ma własne jajo, i czy tam siedzi Debian z AA,
czy Centus albo Andorid z SELinuxem czy OpenBSD, żadnej istotnej interakcji z system gospodarza tutaj nie ma.
To eliminuje też niektóre zagrożenia (oczywiście nie wszystkie).
[...]
Ale prawdziwa wirtualizacja to trochę twardsza bariera niż chroot na sterydach.
Zwłaszcza w kontekście np niedawnego CVE-2022-0847 czy wcześniejszego CVE-2016-5195.
Mówisz tak jakby kvm breakout czy inne cve dla wrtualziacji nieśmiało. Separacja namespaceów jest bardziej skomplikowana niż sama wirtualizacja ale dostarcza taki sam poziom izolacji przy znacznie mniejszych zasobach
Jacekalex napisał(-a):
Oczywiście do KVM nie ma gotowych obrazów zdefiniowanych w plikach composer.json,
dlatego z biznesowego punktu widzenia nie nadają się na szybki i łatwy zysk z konteneryzacji.
Tutaj nawet nie chodzi na szybki deployment tylko skalowalność.
Offline
urbinek napisał(-a):
Który? Afaik cały rynek cloud idzie w stronę konteneryzacji czy usług serverless.
O ile aplikacja nie wymaga mocnego sprzętu (np SAP) to aplikacje pisze się atomicznie aby można było je skonteneryzować i zarządzać k8s czy innym ranczerem.
Kwestie gówna zwanego rancherem przemilcze, to ponad 5 lat temu działając w oparciu jeszcze o dockera było totalną porażką, przy k8s nie wiele się zmieniło dalej jest tym samym. Dobrze że są inni dyrygenci tej orkiestry.
Serverless to nic innego jak jail ewentualnie kontener z podpiętym storage np. na s3 i to wszystko ładnie ubrane w ładnym marketingowy syf. Wszystko do tego sterowane przez kod w yamlu, czyli ludzie którzy jeszcze 5 lat temu byli linux adminami obecnie są devopsami którzy klepią kod w yaml aby robić to samo co wcześniej tylko nie na baremetalu gdzieś w piwnicy tylko na cloud wielkiego korpo. Ewentualnie robi to programista który za bardzo ma pojęcie o optymalizacji kodu czy systemu, cloud się cieszy bo więcej zarobi.
Rynek się cieszy bo jest taniej bo nie trzeba utrzymywać sprzętu i ludzi, robi to za nich jakieś tam korpo. Szkoda że nie widzą że ciągnie za sobą jakieś to konsekwencje. Nawet głupia nie standardowa konfiguracja jest problemem, bo albo się nie da albo płacisz. Wszedłem tu żeby właśnie przewietrzyć mózg bo trafiłem na taki problem, gdzie jeszcze parę lat temu dałoby się go rozwiązać zmianą jednej linijki w konfiguracji i przeładowaniem usługi. Można by zapomnieć o problemie po 2 minutach a tutaj będę się z tym pieścił jeszcze parę dni.
Analogicznie do świata cloud jest obecnie w opensource albo jest klepane po raz 1000 to samo w innym stylu ewentualnie jest robione scentralizowanie i nazywa się systemd-shitapp i nie ma kompatybilności wstecznej, masz tak żyć a nie inaczej.
Offline
@urbinek i @mati75
Nie ma się co nakręcać.
Operatorzy serwisów Cloud zrobili z Dockera i K8s żyłę złota.
Nie da się w dockerze i k8s ustawić sztywnych limitów procka i pamięci, bo nie ma punktu odniesienia czyli danych o faktycznym hardware.
W ten sposób choćbym nie wiem, jak opakował appkę w dockerze konfiguracją, to i tak czasem mi przyślą rachunek za "przekroczenie takich a siakich zasobów" i pociągną z karty dodatkową kasę.
Cloud jest taki wspaniały, bo da się w nim efektywniej wyciągać kasę od leszczy, grożąc im skasowaniem danych i zamknięciem usługi.
Marzeniem każdej korpo jest możliwość zwiększania przychodu od dotychczasowej grupy klientów.
Cloud daje tu możliwości wcześniej nieznane.
W chmurze, czy to GCP, czy AWS albo Azure, nie ma nigdy pewności, ile docelowo zapłacisz.
To jest ich genialna siła.
Za infrastrukturę Fastly czy Akamai płacą akcjonariusze, Amazon czy Google nie mają tutaj żadnych sztywnych kosztów, za to zapewniają sobie wjazd do karty kredytowej tysięcy klientów na kwoty, które bez większych problemów mogą czasem powiększyć o 30% albo 300% motywując to dowolnie.
To jest dużo efektywniejszy i zyskowniejszy model gospodarczy niż robi np Walmart czy Biedronka, bo tradycyjne markety mają koszty i dosyć sztywne ceny.
Offline
Jacekalex napisał(-a):
Nie da się w dockerze i k8s ustawić sztywnych limitów procka i pamięci, bo nie ma punktu odniesienia czyli danych o faktycznym hardware.
W k8s da się ograniczać pody. Tylko trzeba o tym wiedzieć i umieć a z tym wśród "specjalistów" na rynku trudno.
Offline
Pamięć ram faktycznie można na sztywno ustawić wartość, ale procka już nie.
Cgroup nie daje szansy na ustawienie sztywno czasu procka tylko na jego podzielnie przez wartości ułamkowe wg kilku algorytmów.
A potem przychodzi rachunek za przekroczenie czasu procka...
Tak się przypadkowo składa, że docker i k8s bazują w limitowaniu procka i RAM na cgroup.
Ostatnio edytowany przez Jacekalex (2022-03-25 10:16:40)
Offline
Jacekalex, niepotrzebnie kombinujesz ze skryptami. Dlaczego używasz legacy a nie unified? LXC pięknie wspiera cgroupv2.
Udało mi się w końcu dojść co i jak należy ustawić.
Wrzucę mój config, może przyda się komuś:
┌─[doskanoness@gentoo] - [~] - [2022-03-27 11:16:21] └─[0] <> cat /etc/cgroup/cgconfig.conf ⚡[▶▶▶▶▶▶▶▶▶▷] # # Copyright IBM Corporation. 2007 # # Authors: Balbir Singh <balbir@linux.vnet.ibm.com> # This program is free software; you can redistribute it and/or modify it # under the terms of version 2.1 of the GNU Lesser General Public License # as published by the Free Software Foundation. # # This program is distributed in the hope that it would be useful, but # WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # #group daemons/www { # perm { # task { # uid = root; # gid = webmaster; # } # admin { # uid = root; # gid = root; # } # } # cpu { # cpu.shares = 1000; # } #} # #group daemons/ftp { # perm { # task { # uid = root; # gid = ftpmaster; # } # admin { # uid = root; # gid = root; # } # } # cpu { # cpu.shares = 500; # } #} # #mount { # cpu = /mnt/cgroups/cpu; # cpuacct = /mnt/cgroups/cpuacct; #} # group doskanoness { perm { task { uid = doskanoness; gid = doskanoness; } admin { uid = doskanoness; gid = doskanoness; } } cpu {} cpuset {} hugetlb {} io {} memory {} pids {} } ┌─[doskanoness@gentoo] - [~] - [2022-03-27 11:15:30] └─[0] <> cat /etc/cgroup/cgrules.conf ⚡[▶▶▶▶▶▶▶▶▶▷] # /etc/cgrules.conf #The format of this file is described in cgrules.conf(5) #manual page. # # Example: #<user> <controllers> <destination> #@student cpu,memory usergroup/student/ #peter cpu test1/ #% memory test2/ # Terminal doskanoness:/usr/bin/konsole * doskanoness # LXC doskanoness:/usr/bin/lxc-attach * doskanoness doskanoness:/usr/bin/lxc-autostart * doskanoness doskanoness:/usr/bin/lxc-cgroup * doskanoness doskanoness:/usr/bin/lxc-checkconfig * doskanoness doskanoness:/usr/bin/lxc-checkpoint * doskanoness doskanoness:/usr/bin/lxc-config * doskanoness doskanoness:/usr/bin/lxc-console * doskanoness doskanoness:/usr/bin/lxc-copy * doskanoness doskanoness:/usr/bin/lxc-create * doskanoness doskanoness:/usr/bin/lxc-destroy * doskanoness doskanoness:/usr/bin/lxc-device * doskanoness doskanoness:/usr/bin/lxc-execute * doskanoness doskanoness:/usr/bin/lxc-freeze * doskanoness doskanoness:/usr/bin/lxc-info * doskanoness doskanoness:/usr/bin/lxc-ls * doskanoness doskanoness:/usr/bin/lxc-monitor * doskanoness doskanoness:/usr/bin/lxc-snapshot * doskanoness doskanoness:/usr/bin/lxc-start * doskanoness doskanoness:/usr/bin/lxc-stop * doskanoness doskanoness:/usr/bin/lxc-top * doskanoness doskanoness:/usr/bin/lxc-unfreeze * doskanoness doskanoness:/usr/bin/lxc-unshare * doskanoness doskanoness:/usr/bin/lxc-update-config * doskanoness doskanoness:/usr/bin/lxc-usernsexec * doskanoness doskanoness:/usr/bin/lxc-wait * doskanoness # Code editors doskanoness:/usr/bin/vscode * doskanoness doskanoness:/usr/bin/subl * doskanoness doskanoness:/usr/bin/atom * doskanoness doskanoness:/usr/bin/kate * doskanoness doskanoness:/usr/bin/vim * doskanoness doskanoness:/usr/bin/nano * doskanoness # IDEs doskanoness:/home/doskanoness/clion-2021.2.3/bin/clion.sh * doskanoness doskanoness:/home/doskanoness/pycharm-2021.2.3/bin/pycharm.sh * doskanoness doskanoness:/home/doskanoness/RubyMine-2021.2.3/bin/rubymine.sh * doskanoness doskanoness:/home/doskanoness/WebStorm-212.5457.55/bin/webstorm.sh * doskanoness doskanoness:/home/doskanoness/DataGrip-2021.3.1/bin/datagrip.sh * doskanoness # End of file
Offline
doskanoness napisał(-a):
Jacekalex, niepotrzebnie kombinujesz ze skryptami. Dlaczego używasz legacy a nie unified? LXC pięknie wspiera cgroupv2.
...
Wieki temu, zanim cgroupv2 sie rpzyśnił komukolwiek, zrobiłem sobie konfigurację i działa grzecznie.
Poza tym w Debianie Systemd automatycznie włącza cgroup_hybrid, ale ja mam Gentoo z OpenRC, i w ogóle zrezygnowałem z konfiguracji cgroup via OpenRC żeby mi bajzlu w konfiguracji nie robił,
i tak już zostało.
Jak kiedyś cgroupv1 przestanie działać, to wtedy się będę martwił, na razie chodzi bardzo grzecznie, żadnych problemów z nim nie mam.
Docker też się nie skarży:
docker system info | grep -A1 cgroup Cgroup Driver: cgroupfs Cgroup Version: 1
Pozdro
Ostatnio edytowany przez Jacekalex (2022-03-28 06:37:29)
Offline
Strony: 1