собственно сабж товарищи. Никто не встречал какой-то опенсорс платформы, которую можно было бы самому обучать для своих нужд? я понимаю что самом врядли обучишь до уровня опенаи, но всетаки было бы интересно попробовать
Интересует не запрет запуска 'su', а полный запрет на уровне системных вызовов.
Привет. Увидел новость про скриншотер и решил написать свой с минимальным набором функций.
Там куча проблем граблей с wayland. На чем писать чтобы не было зависимости от оконного менеджера? QT, GTK, boost?
Начну как лабораторки по учебе а потом может и линукс примут пакетом.
Собсна, сабж. На следующих URI 404:
Что ещё заблокировать и как к этому относится администрация? При необходимости могу перестать проксировать ЛОР в Ygg. Адрес и домен прокси: http://[300:eaff:7fab:181b::e621]:1643, http://lor.skunk.conf
Конфиги:
nginx.conf:
server {
listen [300:eaff:7fab:181b::e621]:1643;
listen [300:eaff:7fab:181b::e621];
server_name lor.skunk.conf;
location / {
proxy_http_version 1.1;
proxy_pass https://www.linux.org.ru/;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
include nginx_lor.conf;
}
}
nginx_lor.conf:
proxy_set_header Accept-Encoding "";
sub_filter_once off;
sub_filter 'https://www.linux.org.ru/' 'http://$server_addr/';
sub_filter_types *;
sub_filter '<script' '<!-- <script';
sub_filter '</script>' '</script> -->';
sub_filter '<img src="/adv/qrator-box.png" width="250" style="max-width: 100%; height: auto" alt="Protected by Qrator">' '';
sub_filter '<a href="https://www.linux.org.ru/register.jsp">Регистрация</a>' '';
sub_filter '<a id="loginbutton" href="https://www.linux.org.ru/login.jsp">Вход</a>' '';
if ($uri ~ "login") {
return 404;
}
if ($uri ~ "register") {
return 404;
}
if ($uri ~ "add") {
return 404;
}
Галерею потом починю, сейчас мне лень этим заниматься.
Проект software radio systems Radio Access Network или srsRAN нацелен на реализацию стеков 4G/LTE и 5G. Ранее проект известен был как srsLTE.
( читать дальше... )
>>> Подробности
Здравствуйте. Имеется три вопроса.
Первый вопрос:
У меня имеется домашний сервер, который находится за NAT.
Есть VDS сервер с внешним IP адресом (123.123.123.123).
Стоит WireGuard туннель между серверами. VDS сервер имеет IP 10.66.66.1 а домашний сервер 10.66.66.2
Хочу спросить, правильно ли я настроил iptables чтобы при обращении на внешний ip трафик свободно ходил к серверу за NAT туда и обратно? Или нужно что-то добавить?
Использую такие правила:
iptables -t nat -A PREROUTING -d 123.123.123.123 -p tcp -m multiport –dports 1338,8083,80,443,3306 -j DNAT –to-dest 10.66.66.2
iptables -t nat -A PREROUTING -d 123.123.123.123 -p udp -m multiport –dports 1338,8083,80,443,3306 -j DNAT –to-dest 10.66.66.2
iptables -t nat -A POSTROUTING -s 10.66.66.2 -j MASQUERADE
Правда почему-то MASQUERADE в итоге прописано два, убрать возможно какой нужно?
root@vds:~# iptables -t nat -L POSTROUTING –line-numbers
Chain POSTROUTING (policy ACCEPT)
num target prot opt source destination
1 MASQUERADE all – 10.66.66.2 anywhere
2 MASQUERADE all – anywhere anywhere
Второй вопрос:
На домашнем сервере стоит веб сервер (HestiaCP) и когда клиент заходит на сайт его IP определяется как 10.66.66.2, что я сделал не так?
Что возможно поменять, чтобы отображался именно IP клиента?
Третий вопрос:
Читал в интернете, что нужно добавлять еще такие правила:
iptables -t nat -A POSTROUTING -s 10.66.66.2 -p tcp -m multiport –sports 1338,8083,80,443,3306 -j SNAT –to-source 123.123.123.123
iptables -t nat -A POSTROUTING -s 10.66.66.2 -p udp -m multiport –sports 1338,8083,80,443,3306 -j SNAT –to-source 123.123.123.123
Их так же нужно добавлять или нет? Так как к примеру в проблеме с получением IP адреса клиента они мне не помогли.
Буду благодарен за ответы.
Нужна помощь в правильной настройке связки Wireguard/Shadowsocks для обфускации канала Wireguard. Клиент имеет прямое соединение с WG/SS-сервером (без роутера). По различным статьям интернетов удалось сделать следующее:
$ wget https://raw.githubusercontent.com/angristan/wireguard-install/master/wireguard-install.sh
$ chmod +x wireguard-install.sh
$ ./wireguard-install.sh
$ apt install shadowsocks-libev
[Interface]
Address = 10.66.66.1/24,fd42:42:42::1/64
ListenPort = <wg_port>
PrivateKey = WGGXx8...
PostUp = iptables -I INPUT -p udp --dport <wg_port> -j ACCEPT
PostUp = iptables -I FORWARD -i enp0s7 -o wg0 -j ACCEPT
PostUp = iptables -I FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o enp0s7 -j MASQUERADE
PostUp = ip6tables -I FORWARD -i wg0 -j ACCEPT
PostUp = ip6tables -t nat -A POSTROUTING -o enp0s7 -j MASQUERADE
PostDown = iptables -D INPUT -p udp --dport <wg_port> -j ACCEPT
PostDown = iptables -D FORWARD -i enp0s7 -o wg0 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o enp0s7 -j MASQUERADE
PostDown = ip6tables -D FORWARD -i wg0 -j ACCEPT
PostDown = ip6tables -t nat -D POSTROUTING -o enp0s7 -j MASQUERADE
### Client 1
[Peer]
PublicKey = PXEAaW...
PresharedKey = GYSqh4...
AllowedIPs = 10.66.66.2/32,fd42:42:42::2/128
{
"server": "0.0.0.0",
"server_port":<ss_port>,
"password":"<ss_password>",
"mode":"tcp_and_udp",
"method":"chacha20-ietf-poly1305",
"timeout":300
}
$ systemctl restart shadowsocks-libev.service
$ wg-quick up wg0
$ systemctl status wg-quick@wg0.service
$ systemctl status shadowsocks-libev.service
…………………………………………….
$ sudo apt install wireguard shadowsocks-libev
- Get build utilities (mk-build-deps) -
$ sudo apt install pkg-config gettext build-essential autoconf \
libtool libpcre3-dev asciidoc xmlto libev-dev libudns-dev \
automake libmbedtls-dev libsodium-dev git libc-ares-dev \
devscripts equivs
- Get Shadowsocks sources -
$ git clone --recurse-submodules https://github.com/shadowsocks/shadowsocks-libev.git
- Build Shadowsocks -
$ cd shadowsocks-libev
$ ./autogen.sh
$ dpkg-buildpackage -b -us -uc
- Install Shadowsocks -
$ sudo dpkg -i ../shadowsocks-libev*.deb
[Interface]
PrivateKey = gOfC03...
Address = 10.66.66.2/32,fd42:42:42::2/128
DNS = 1.1.1.1,1.0.0.1
[Peer]
PublicKey = JE0hSg...
PresharedKey = GYSqh4...
Endpoint = 127.0.0.1:1080
AllowedIPs = 0.0.0.0/0,::/0
{
"server":"<ip_server>",
"server_port":<ss_port>,
"local_address": "0.0.0.0",
"local_port":1080,
"password":"<ss_password>",
"mode":"tcp_and_udp",
"method":"chacha20-ietf-poly1305",
"tunnel_address": "127.0.0.1:<wg_port>",
"timeout":300
}
$ sudo wg-quick up wg0-client
$ sudo ip route add <ip_server> via 192.168.8.1 dev eth0
$ sudo ss-tunnel -v -c /etc/shadowsocks-libev/config.json
... check Wireguard state
$ sudo wg
... [FIX: wg-quick not found]
$ sudo apt install resolvconf
... [FIX: RTNETLINK answers: Permission denied]
# edit /etc/sysctl.conf :
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0
$ sudo sysctl -p
... xx.xx.xx.xx 10.66.66.2 TCP 212 [TCP Spurious Retransmission] 443 → 34852 [ACK] Seq=2737 Ack=518 Win=28160 Len=160 TSval=165036359 TSecr=1700846827
... 10.66.66.2 xx.xx.xx.xx TCP 64 [TCP Dup ACK 223#2] 34852 → 443 [ACK] Seq=645 Ack=4246 Win=65536 Len=0 TSval=1700847089 TSecr=165035936 SLE=2737 SRE=2897
... xx.xx.xx.xx 10.66.66.2 TCP 52 [TCP Previous segment not captured] 443 → 34816 [FIN, ACK] Seq=4246 Ack=606 Win=28160 Len=0 TSval=165036378 TSecr=1700846830
... 10.66.66.2 xx.xx.xx.xx TCP 64 [TCP Dup ACK 338#1] 50268 → 443 [ACK] Seq=605 Ack=1 Win=65536 Len=0 TSval=1700848614 TSecr=165037871 SLE=4105 SRE=4247
... xx.xx.xx.xx 10.66.66.2 TCP 1420 [TCP Out-Of-Order] 443 → 50268 [ACK] Seq=1369 Ack=605 Win=28672 Len=1368 TSval=165037871 TSecr=1700848332 [TCP segment of a reassembled PDU]
... 10.66.66.2 xx.xx.xx.xx TCP 1500 [TCP Retransmission] 34838 → 443 [ACK] Seq=2001 Ack=4495 Win=65536 Len=1448 TSval=1700847448 TSecr=165036628
...
... fd42:42:42::1 fd42:42:42::2 ICMPv6 128 Destination Unreachable (no route to destination)
INFO: [udp] remote_recv_recvfrom fragmentation, MTU at least be: 1602
INFO: [udp] remote_recv_sendto fragmentation, MTU at least be: 1547
Разработчики не придают этому значения.
Господа, что вы думаете о необходимости ведения логов при частном применении (не для обхода всяких РКН)?
Проблема еще заключается в том, что у WG нет нативных средств ведения логов. Есть только через dyndbg, но он «закакивает» весь dmesg. Может есть какая-то возможность включить только определенные события или как-то отучить его загаживать dmesg?
Я тут в очередной раз пытаюсь освоить программирование микроконтролеров. Захотелось написать такой полу-ЖЖ, полу-туториал (как говорится - хочешь разобраться в чём-то, объясни это другим). Может кто почерпнёт или подскажет чего полезного.
Если интерес будет, буду продолжать.
Итак осваиваем STM32 не как нормальные люди.
Примерный план:
Подключить его к компьютеру и убедиться, что там что-то происходит. Использовать будем st-util и gdb.
Написать простейшую программу на ассемблере, которая в цикле прибавляет регистр, скомпилировать из неё прошивку, залить на плату и пронаблюдать её работу. Использовать будем binutils и st-flash.
Поморгать диодом (на ассемблере же).
Переписать осмысленный код на С (дальше всё на С).
Переписать моргание с использованием таймера, чтобы внести свой вклад в борьбу с глобальным потеплением.
Сказать внешнему миру «Hello world» через UART.
Переписать «Hello world» с помощью CMSIS, уже с пониманием того, что там происходит.
На этом этапе начальное освоение микроконтроллеров можно считать завершённым. Дальше, видимо, сотни страниц датащитов по записи нужных битов в нужные места, или использование готовых библиотек. В любом случае навыки из списка выше полезны при использовании любых библиотек, т.к. всё растёт из этой базы.
Сразу скажу, что в процессе будет использовано достаточно много инструментов вроде make, ld, gdb, as, gcc и тд, по каждому из них можно книги писать (и пишут). Поэтому, конечно, углубляться в них я не буду, а напротив буду использовать в максимально примитивном виде.
Ниже ссылки на мануалы, где можно подробней раскрыть тему. Ожидается, что читатель будет активно ими пользоваться.
Написал большой и годный мануал с примерами, как подключать дисплеи к одноплатникам без нормального видеовыхода (OrangePi, привет).
Не забыл расписать и про использование дисплеев из бытовых устройств, описал известные физические протоколы для подключения к дисплеям.
Пробовал обновить на текущем сервере падает в ошибку data dictionary и больше не заводится (из-за ошибочных временных таблиц), благо делал для тестов копию сервера.
Собственно какие варианты? Как действовать, на сервере постоянно работают пользователи
Предисловие: есть небольшой видеосервис, на котором храняться записи лекций ВУЗа. Ранее сие было банальной файлопомойкой, но в прошлом году дошли руки и был реализован «свою ютуб с блэкджеком и павлинами» - лекции можно посмотреть, можно скачать, можно свой плей-лист сформировать. Ну в общем такое... Крутится все на обычном компе (i7, DDR3), на борту Debian.
Дабы все было однотипно и красиво мы начали кодировать видео в одинаковый формат (ffmpeg), что логично - и места меньше занимает и админить такое проще. Но вот тут возникла проблема - есть необходимость конвертнуть огромное количество видосов, человек писал лекции несколько лет.
Подскажите, есть ли смысл (понимаю что есть) прикупить видеокарту и кодировать ffmpeg с использованием GPU?
Какую из дешманских видеокарт лучше взять под такие задачи?
Перемещено hobbit из general
Есть готовый загрытый продукт, который в своем составе использует SQL БД, таблиц много (около сотни), полей в них тоже много, иногда чтобы сделать запрос для сбора данных из 2 таблиц, нужно транзитом пройти еще несколько и очень хотелось бы иметь графическое представление этой БД в виде схемы (какие таблицы через какие поля связаны), для небольшой БД можно и самому нарисовать,но тут прям МНОГО и хотелось бы софтину, в которую можно загрузить схему и получить список таблиц (с полями, типами, комментариями), связи сам потом дорисовать могу. Ну и экспорт этого дела в какой-нибудь png.
UPD: Отрисовал в Draw.io, из минусов - нужен мощный калькулятор, иначе подтупливает на большом числе элементов на схеме.
Здравствуйте всем. Если Вы пользуете тарпит endlessh. Боты давно его игнорируют. Ждут 10-20 сек и отваливают. Но, я усмотрел интересную вещь. Боты нападают сразу 20-30 конектов. Тупые писатели этих ботов проперлись. Если сделать так:
iptables -A INPUT -p tcp --syn --dport 22 -m connlimit --connlimit-above 1 -j REJECT
Вот простой пример программы чтения из raw socket. Ищется в инете чуть-ли самый первый.
/*** IPPROTO_RAW receiver ***/
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/ip.h>
#include <arpa/inet.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int s;
struct sockaddr_in saddr;
char packet[50];
if ((s = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) {
perror("error:");
exit(EXIT_FAILURE);
}
memset(packet, 0, sizeof(packet));
socklen_t *len = (socklen_t *)sizeof(saddr);
int fromlen = sizeof(saddr);
while(1) {
if (recvfrom(s, (char *)&packet, sizeof(packet), 0,
(struct sockaddr *)&saddr, &fromlen) < 0)
perror("packet receive error:");
int i = sizeof(struct iphdr); /* print the payload */
while (i < sizeof(packet)) {
fprintf(stderr, "%c", packet[i]);
i++;
}
printf("\n");
}
exit(EXIT_SUCCESS);
}
Работает, но только когда пакеты посылаются на петлевой интерфейс (127.0.0.1). А если послать их по реальной физичской сети, то программка ничего не читает из сокета. В чем может быть дело? tcpdump пакеты ловит, проверено, т.е. физически они передаются.Решил написать заметку про kubernetes. Сам работаю с небольшим кластером, делаю всё один, а также в силу характера докапываюсь до всех мелочей, поэтому волей-неволей пришлось разбираться со многими вещами. Может кому полезно будет.
Ничего конкретного писать не буду, буду писать концептуально и про свой опыт. Конкретной информации в интернете хватает. Также многие моменты буду упрощать, просьба не цепляться к мелочам.
Предполагаю, что вы знаете про докер, иначе смысла читать дальше нет. Кубернетес это такая надстройка над докером, которая:
Объединяет несколько разных компьютеров в один логический кластер.
Позволяет создавать и запускать контейнеры. Сильно похоже на docker-compose, но k8s позволяет не указывать конкретный компьютер, на котором будет запущен контейнер, а сам его выбирает.
Обеспечивает виртуальную сеть между всеми контейнерами в пределах кластера, обеспечивает т.н. service discovery, а также обеспечивает балансировку нагрузки междду сервисами внутри этой виртуальной сети. Т.е. я могу во-первых в своей программе по днс-имени postgres-1 узнат IP-адрес первого контейнера с постгресом, а во-вторых по днс-имени postgres-ro получить дважды виртуальный IP-адрес, при соединении на который моё соединение уйдёт на случайный инстанс постгреса.
При надлежащей настройке делает это всё высокодоступным и масштабируемым. Т.е. при исчезновении по любым причинам любого сервера из вашего кластера, он продолжает оставаться работоспособным. А также запускает больше контейнеров при повышении нагрузки на сервис.
Таким образом конкретный сервер абстрагируется, для контейнера не важно, где он запущен, он видит весь кластер.
На самом деле современный k8s работает не поверх докера, а поверх легковесной абстракции CRI и её реализации обычно в виде containerd, но это частности
В принципе это надо всем, кому не хватает одного сервера. Хотя не все понимают, что это им надо. В общем-то можно и полуручными способами обходиться довольно долго. Но нужно ли - вопрос открытый.
Альтернативы я знаю следующие:
Hashicorp Nomad. Штука похожая на k8s, но гораздо менее распространённая. По слухам настраивать гораздо проще. Сам не пробовал. Я человек мейнстрима и выбираю то, что выбирает большинство.
Docker Swarm. В принципе очень похоже на следующий шаг после docker compose. Если вам перестало хватать одного сервера, на котором всё было через docker compose, а времени/желания изучать полностью новую платформу у вас нет, наверное это логичный шаг. Его я сам тоже не пробовал.
Проприетарные облачные решения. У всех крупных вендоров они есть. К примеру AWS Fargate. Главный минус: ваше приложение будет прибито гвоздями к этому вендору. Съехать с него малой кровью не получится.
Ценность kubernetes вижу в следующем:
Независимость от вендора. У каждого облака есть managed kubernetes. И хотя детали у них отличаются, но всё же сам kubernetes один и тот же. Переехать с одного облака на другое не намного сложней, чем переехать с Debian на RHEL.
Опция селф-хоста. Если ни одно облако не нравится, всегда есть опция купить ящик с SuperMicro и поставить всё туда.
Популярность. По большому счёту альтернативы на сегодня не взлетели. Специалистов по k8s найти проще, чем других. Документации в интернете очень много. Есть и компании, которые будут админить ваш кластер за вас.
Основных способов два: либо своими силами поднимать кластер, либо использовать управляемое решение от облачного вендора.
Если своими силами поднимать кластер, надо понимать, что для кластера имеются следующие требования:
Кластеру нужен балансировщик нагрузки. Это когда у вас есть публичный IP-адрес, и N адресов. И соединения, приходящие на этот публичный адрес будут равномерно распределяться на эти N адресов. Балансировщик нагрузки должен мониторить доступность клиентов и вовремя включать/выключать их.
Кластеру нужно сетевое хранилище. Это когда вы можете какой-то сетевой диск подключить к любому (одному) компьютеру и потом в линуксе он должен появиться, как /dev/sdc.
Первый пункт можно сделать самому через haproxy. Но не очень просто, если делать по уму (отказоустойчиво). Ну крутые дядьки, наверное, чем всякие там cisco такое могут делать вообще уровнем ниже, с резервированием на уровне проводов. Впрочем у них и грохается всё круто.
Если у вас гордый кластер из одного компьютера, ему балансировщик нагрузки не нужен.
Также можете тупо дать каждому серверу публичный адрес и все их вбить в DNS с коротким TTL. Не знаю, можно ли считать это балансировкой нагрузки, но с какими-то оговорками работать будет… Ну это так, из разряда дёшево и сердито.
Как сделать второй пункт самому, я не знаю. Есть ceph, есть ещё что-то, но это всё сложно. В принципе второй пункт не абсолютно критичен и если не запускать в кластере никакие сервисы, которым требуется что-то хранить, то без него можно обойтись. Также можно использовать локальный диск сервера, но надо понимать, что ваш контейнер с БД на другом сервере уже запустить не получится, данные магическим образом не переместятся. Ну и в целом использование локального диска в кубернетесе довольно геморное. Рекомендовать я его точно не буду. Есть какие-то решения, которые берут локальные диски всех серверов и автомагическим образом из них делают доступное сетевое хранилище, я такими не пользовался и в магию не верю.
Обе проблемы легко решаются, если вы своими силами поднимаете кластер, используя облачного провайдера, который предоставляет вам вышеописанные сервисы. Я именно так и делаю: мой провайдер использует OpenStack и Ceph и балансировщик нагрузки с сетевыми дисками у него доступен (под капотом балансировщик нагрузки это тупо две виртуалки с haproxy, но для меня это не важно).
Ещё с сетевыми дисками важно, чтобы был CSI-драйвер для них. Для OpenStack такой есть. Т.е. kubernetes должен этому драйверу отдавать команду «подключи мне диск pvc-7672ffed-9ddc-4df4-affd-a717a1c11c79 на сервер 10.160.3.160» а драйвер должен отвечать «смонтировано в /dev/sdg».
Для своего кластера есть следующие подходы:
kubeadm. Это набор софта от разработчиков kubernetes, который устанавливает и обновляет компоненты кластера. Я использую этот подход. Под низом стоит обычный линукс. У меня это debian minimal. Проблем с ним я не испытывал. Вообще народ обычно убунту использует, меня от неё воротит. По идее можно и на центоси, есть и более экзотичные варианты вроде CoreOS, я не вижу смысла тут использовать что-то необычное.
Talos Linux. Это офигенная штука: ядро линукса плюс необходимый набор софта плюс сам кубернетес. Это всё идёт как один ISO и грузится в память. Ему даже диск не нужен. И сразу работает. Короче это по сути kubernetes как ОС. Я слишком поздно про него узнал, вероятно я бы его предпочёл. Надо понимать, что штука относительно новая и экзотичная, но я от него в восторге. По крайней мере в концептуальном восторге, может на практике вылезут нюансы.
kubespray это огромная куча ansible скриптов, которые обещают, что за тебя всё сделают и поставят. Сам не пробовал, меня такая концепция не устраивает. Если я и буду пользоваться кучей ansible скриптов, то только теми, которые пишу сам. Туда же дистрибутив от Flant. Есть, наверное, и менее популярные решения.
Kubernetes the hard way. Это когда ты руками всё настраиваешь сам, ставишь каждый компонент и тд. В целом ничего сверхъестественного тут нет, весь kubernetes это несколько сервеных программ плюс кучка настроек для них вроде своего УЦ с сертификатами и прочим. Но это ненужное усложнение и оправдано только для изучения потрохов. Сам я его не делал и страданий от этого не испытываю. В общем что-то вроде Linux From Scratch.
Управляемые решения я сам не использовал. В целом они решают некоторые проблемы и добавляют свои. Самый главный плюс управляемого решения: хостер будет сам управлять серверами. К примеру при росте нагрузки хостер сам создаст дополнительные серверы, установит туда k8s и добавит их в кластер. При снижении нагрузки он эти серверы выведет из кластера и уничтожит. Это называется node autoscaling. В моём кластере такого нет. В принципе это можно и самому сварганить, если снизу инфраструктура с каким-то API, которая позволяет создавать и удалять серверы. Но это нетривиально и требует программирования.
В целом моё мнение на текущий момент: лучше использовать управляемый k8s от серьёзного облака. Он не так уж много сил экономит, как они это пытаются показать, но всё же сколько-то - экономит, а денег за него обычно не просят. На втором месте: использовать k8s поверх облака, которое даёт нужные «примитивы»: балансировщик нагрузки и сетевое хранилище. На третьем месте: использовать k8s на своём железе.
Первое преимущество Kubernetes похоже на преимущество докера, которое я не сразу осознал. В докере помимо технологии есть ещё и коммьюнити. Это тысячи людей, которые собирают готовые пакеты. Если мне нужен postgres или wordpress или ещё что угодно, скорей всего это кто-то уже собрал. И даже если я решу собирать свой образ, я как минимум смогу посмотреть на чужие докерфайлы, а скорей всего мне хватит чужих. Это экономит много времени и сил. В кубернетесе похожая тема: для него создано куча софта и деплойментов, которые позволяют в пару строк деплоить в кластер довольно сложные конфигурации. К примеру прометей, собирающий метрики, локи, собирающий логи, ещё кучка вспомогательных агентов и графана, уже настроенная на отображение всего этого, ещё и с кучей готовых дашбордов, которые не стыдно директору показать. Почти для любого софта, который я хочу запустить в своём кластере, есть хельм от производителя, в котором всё уже прописано. И даже если я решу писать дескрипторы сам, я в этот хельм смогу посмотреть.
Второе преимущество Kubernetes на самом деле тоже похоже на преимущество докера, которое я тоже не сразу осознал. Это сближение программистов и админов. В классическом древнем подходе программист пишет код, сборщик собирает из этого кода артефакт, а деплоер устанавливает этот артефакт на сервер. Докер позволяет сблизить программиста и сборщика. Когда программист указывает в машинном виде все инструкции для сборки и все «входные» артефакты. Причём не в виде кучи непонятно каких скриптов, а в относительно стандартизованном виде. Вот Kubernetes с его ямлами делает похожую задачу и сближает программиста и деплоера. Когда ты можешь в своём софте написать в машинно-читаемом виде - какие volume-ы нужны твоему софту, какие конфиги, какие переменные окружения, какие порты твой софт выставляет и тд.
Третье преимущество в том, что есть некоторые уникальные софтины. К примеру я пускаю БД в кластере. БД управляется через оператора. Оператор это такая программа (которая тоже запущена в кластере) которая создаёт контейнеры с БД, настраивает их как надо и как бы следит за ними. К примеру я буквально несколькими строчками настроил запуск постгреса в двух копиях с периодическими бэкапами в S3 и постоянными бэкапами wal-логов туда же. В итоге имею high-available СУБД кластер с бэкапом и возможностью откатиться с гранулярностью в 5 минут. Руками такое настраивать я бы наверное несколько дней минимум потратил. Понятно, что если сломается, то в общем случае для починки придётся разбираться что там как устроено. Ну пока не ломалось. Может и не сломается.
Вот эти преимущества позволяют мне рекомендовать использовать Kubernetes даже там, где сегодня нет никакого кластера. Т.е. просто вместо докера, на обычном одном сервере. В таком варианте, кстати, не нужен ни балансировщик нагрузки, ни сетевые диски.
Вот это, наверное, самый важный раздел и то, на что частично отличается от того, что я читаю вокруг.
1.1. А ещё желательно иметь два кластера. Один тестовый, а один боевой. И тестировать свои эксперименты на тестовом. Лично у меня такой возможности нет, я работаю в компании, которая экономит на всём, и $300 в месяц на тестовый кластер это дораха. Поэтому я написал нужные terraform скрипты и прочее, что позволяет мне поднимать тестовый кластер за 15 минут, а потом опускать его. Но лучше не экономить на спичках и держать два одинаковых кластера.
Требования к квалификации. Для того, кто с k8s не работал, там всё будет новое. И хотя ничего особенно сложного там нет, но объём знаний всё же существенный. В целом готовьтесь потратить несколько месяцев на изучение и работу с тестовым кластером. Не вздумайте сходу переводить прод на k8s, если он нужен кому-то кроме вашей мамы. Также надо понимать, что kubernetes очень плотно работает с линуксом. cgroups, iptables, ebpf - эти слова не должны вводить вас в ступор (ebpf меня в ступор вводят, в частности поэтому я отказался от cilium).
Он провоцирует к обезяньнему девопсингу. Этим термином я называю деятельность по копипасту непонятных команд с надеждой получить блестящее и пердящее UI. Я уже выше приводил пример с графаной, когда одной командой можно поставить около десятка сложнейшего преднастроенного софта. Вот это слишком провоцирует. А когда этот сложнейший преднастроенный софт сломается, то обезьяна ничего сделать не сможет. Поэтому обезьяньи порывы надо в себе подавлять и пользоваться только тем, в чём ты хорошо разобрался. А если не разобрался - то сидеть и разбираться. А когда уже разберёшься, тогда можно и готовыми комплектами пользоваться, хорошо понимая, что там где или хотя бы где посмотреть можно.
В целом нужно соблюдать баланс между написанием всего самому и использованием всего готового. Тут обе крайности вредны. На первое времени не хватит. Второе чревато последствиями, ты понятия не имеешь, что происходит у тебя в кластере.
В нём «из коробки» нет многого, что можно было бы ожидать от него. К примеру есть ингрессы (это описание входных точек для внешних сервисов), но ингресс-контролера нет, нужно выбирать и ставить, а их, между прочим, штук 15 разных. Да что там ингресс-контролер, там даже этой самой вышеописанной виртуальной сети нет, есть только некие интерфейсы, а реализацию, которая будет эту сеть «настраивать» - надо ставить самому (собственно это первое, что вы будете ставить в только что созданный кластер). Причём этих реализаций опять же штук 10 разных. И муки выбора - flannel, calico, а может модный cilium, а вот тут на реддите ещё про что-то писали, ааа, вот это при некотором складе характера может мучить. Меня мучает. Я боюсь сделать неверное решение. Если что, я выбрал ingress-nginx и calico для вышеописанных пунктов, как наиболее понятные и консервативные решения. Не жалею.
Он провоцирует ставить и настраивать то, что вам в общем-то не особо и надо. Ну вот жили мы с докер-композом, проставляли реплики в конфиге руками и ладно. А тут вроде есть horizontal pod autoscaler, который будет в зависимости от нагрузки запускать больше или меньше реплик, круто же. А для него метрики нужны, надо ещё компонент для метрик поставить. А вот про istio прочитали, он вообще даёт возможность смотреть все запросы между сервисами, а-а-а, это же просто огонь. В общем вроде и не сказать, что это плохо, т.к. это всё даёт лишние возможности, но всё же тут важно не увлекаться. Может оно вам не так уж и надо, раз жили без этого. Каждая софтина это время на изучение документации, это постоянные затраты времени на чтение ченджлогов, обновления, обновления конфигов. А если это ещё и штука вроде istio, которая не сбоку-припёку, а влезает прям между вашими сервисами, то это ещё и потенциальная причина того, что всё сломается и вам придётся ковыряться в ихних кишках в самое неудачное время. Ну и ресурсы тоже каждая софтина требует, ага. Вроде и всё на го написано, вроде и не ресурсоёмко по большому счёту, но потихоньку набегают гигабайты…
Несмотря на то, что я выше написал про докер, на самом деле с самим докером он плохо совместим. И если вам хочется сделать такую простую и понятную штуку, как запуск вашего CI в кластере - типа коммит прошёл, теперь надо docker build сделать, вот это простое желание на самом деле таит в себе столько нюансов, что я в итоге отказался от этого желания и для CI завёл тупо отдельный сервер с докером.
Кубернетес из коробки адски небезопасен. Легко создать под, в котором будет подмонтирован корень вашего сервера. И удалить там всё, азаза. При этом, конечно же, есть все возможности закручивать гайки сколько угодно, но это надо делать. Когда пишешь helm install, обычно оно ставится от cluster-admin и в общем случае может делать с кластером что угодно. Если у вас отдел девопсов, которые там каждый ямл обнюхают и будут это делать каждую неделю, ставя новую версию, ну классно. А если весь ваш девопёс это я, занимающийся этим, когда других задач нет, и джуниор, который сам всё поломает, только доступ дай, то не классно. Поэтому см. пункт выше про отдельный тестовый кластер.
Гитопс. Гитопс это круто и здорово, но я так и не впечатлился. В общем не рекомендую. С одной стороны - да, весь ваш кластер должен лежать у вас в гите, а не в голове и при необходимости подниматься несколькими командами (или несколькими десятками команд, не принципиальная разница, у меня второй вариант). С другой стороны внедрять прям 100% гитопс, когда вам реально надо коммитить в гит, чтобы там что-то срабоатло, я долго пытался это делать на flux, я его неплохо изучил, но в итоге отказался. Опять же если у вас отдел девопсов, которые будут там друг друга ревьюить и мерджить, то наверное ок. Если вам нужно держать не один кластер, а сто кластеров, развернутых и обновляемых из одного репозитория, то конечно ок (хотя тогда вы сами меня учить будете, а не читать это). А если вас один-два человека, ну я решил, что оно не надо. У меня весь репозиторий это terraform-шняга, которая просто создаёт серверы, на этих серверах через cloud-init при создании ставится containerd, kubelet и прочая ерунда, потом я туда по ssh захожу и вбиваю kubeadm join и всё. Это инфраструктура. Второй репозиторий это во-первых кучка скриптов (в основном helm update, чтобы не запоминать это всё), во-вторых кучка kustomize-ов, которые уже ставят либо то, что в helm не обернули (или я не захотел этим пользоваться), либо, собственно, тот софт, ради которого весь этот кластер вообще существует.
Ямлы-ямлы-ямлы-ямлы. Не, я не особо жалуюсь, но всё же в кубернетесе эти ямлы они как-то совсем уж беспонтовые. И дело не в формате, а в том, что они совсем не добавляют синтаксический сахар. Это не является чем-то адски страшным, но когда пишешь
ports:
- name: http
containerPort: 3100
вместо
ports:
http: 3100
или вся эта копипаста
spec:
selector:
matchLabels:
app: loki
template:
metadata:
labels:
app: loki
spec:
containers:
в которой сути около нуля, то это утомляет слегка. В общем синтаксического сахара не хватает. Да, конечно, это можно всё генерировать, но это лишние усложнения. На мой взгляд это должно было бы быть из коробки. А они какие-то свои внутренние структуры просто замапили в JSON и объявили это стандартом. А то, что это будут писать люди, про это никто точно не думал.
Также из коробки поставленный через kubeadm кластер не стабилен и сервер легко роняется одним подом, который решил сожрать всю память (у меня сервер просто перестал отвечать, где там были все эти ваши оом киллеры, я не знаю). Это меня неприятно удивило. А чтобы сделать его стабильным, мне потребовалось потратить не один час на чтение документации и разного рода настройки (в основном резервирование памяти для кублета, системы и тд). Что мешает kubeadm-у прописывать лимиты самому, я не понимаю.
Если у вас три сервера, один сервер упал и вы ожидаете, что кубернетес в ту же секунду, радостно повизгивая, побежит перезапускать все поды на других серверах, то вы сильно ошибаетесь. Во-первых он вообще не сразу поймёт, что сервер упал. Во-вторых он ещё минут 5 подождёт. Ну вдруг тот не упал, а просто устал немножко и присел отдохнуть. Про 5 минут не уверен, кстати, может быть даже 15 минут, сорри, лень смотреть. В общем, как говорится, eventually он таки - да, перезапустит поды на других серверах. Но к вам за это время уже успеют прибежать и наорать, что ничего не работает.
Поэтому high availability это все ваши сервисы, запущенные в двух копиях минимум. Иначе это eventual availability. Что тоже неплохо и лучше, чем unavailability.
Вышеописанные таймауты можно настроить, если что. Но, наверное, не нужно. Я не стал.
Из этого, кстати, вытекает 12. Настроек очень много. Туториалов о том, как эти настройки настраивать - ещё больше. И на ютубе и в тексте. А вот какие значения нужно проставлять, какие плюсы, какие проблемы - тут все резко затыкаются.
Всем привет. Можно ли как-то в kvm эмулировать ssd диск, чтобы в виртуалке он был виден как /dev/nvme0n1?
Есть вот такой вариант - http://blog.frankenmichl.de/2018/02/13/add-nvme-device-to-vm/, но у меня не завелся. При запуске:
qemu-system-x86_64: -drive /var/lib/libvirt/images/nvme.img,if=none,id=D22: warning: short-form boolean option '/var/lib/libvirt/images/nvme.img' deprecated
Please use /var/lib/libvirt/images/nvme.img=on instead
2023-05-17T09:15:11.776360Z qemu-system-x86_64: -drive /var/lib/libvirt/images/nvme.img,if=none,id=D22: Must specify either driver or file
Может, в virtualbox есть что-то подобное? Но, как я понял, там просто скорость вращение диска меняется на 0, и он по прежнему видится, как /dev/sda.
Может как-то можно сэмулировать nvme в систему и прокинуть в kvm как устройство?
Перемещено hobbit из general
Есть пользователи мтс джипона в мск? Как оно вообще?
Хочу взять как резервного провайдера. Почитал их сайт, нужен роутер на оптике, у меня такого нет, придется брать в аренду ихний. Можно же от ихнего воткнуть обычную витую пару к уже имеющимуся?
Как вообще связь, падения?
Можно ли как-то заставить при загрузке получать Ubuntu 22.04.2 ключ шифрования для zfs пула с USB носителя (fat32 с файлом ключа)? Для параметра шифрования keylocation /dev/ssd не годится. Система находится на пуле, так что ключ нужен еще до возможности смонтировать флешку. Как-то через initramfs?
В этот раз через QEMU + KVM + скрипты.
( читать дальше... )
| следующие → |