Да

Ну допустим, а в логах то что на момент падения интефейса? Просто железный интефейс (не бриджовый и не тунельный) положить кривой арп-запрос не может рандомно на статике, это может случится только при кривом dhcp или соседе который заюзал такой же мак или мисконфиг на свиче как правило. Теоретически может переполнится кам-таблица, но тогда это kernel panicом должно кончатся (Хотя и тут зависит от реализации ABI в самой OS)

Если опыта нет, то самое простое решение - ставишь gitlab-раннер на впс, туда же естественно докер и комопоуз и в каждом репозитории отдельный gitlab-ci, который просто docker-compose up делает, если билд докер-образа в компоуз-файле есть.

хорошо, спасибо за помощь)

Берешь дженкинкс и пишешь пайплайн

Подскажите, будьте добры, как на nomad лучше всего решить такой простой кейс:

Одна машина, nomad запущен как сервер и клиент (сервак-песочница).
Запускаю job, состоящую из 1 группы и 2 docker тасков в ней (db и web). Таких джобов планируется с десяток на этом сервере.

Как лучше всего выстроить коннект из web к db в рамках одной группы? Переменные NOMAD_ADDR_db / NOMAD_HOST_ADDR_db содержат 127.0.0.1, вместо докеровского айпишника, т.е не работают.
Выход нашел только в выделении каждого job в user-defined network через network_mode + явное определение network_aliases для каждого таска, но для этого предварительно нужно создавать сеть в докере.

Рассматривал также вариант переключить всё на network_mode = host, но web сервис не умеет в динамические порты, всегда слушает одинаковый.

Есть ли варианты лучше? Возможно я где-то сильно туплю

там, скорее всего, надо связать фронт и бэк

если я правильно помню то port надо статиком объявлять

всем привет, кто нибудь сталкивался с таким ?

на продакшене начал падать xtradb cluster

END OF INNODB MONITOR OUTPUT
============================
InnoDB: ###### Diagnostic info printed to the standard error stream
2021-03-25T15:26:45.595814Z 0 [ERROR] [MY-012872] [InnoDB] [FATAL] Semaphore wait has lasted > 600 seconds. We intentionally crash the server because it appears to be hung.
2021-03-25T15:26:45.595920Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: ut0ut.cc:553 thread 139839427901184
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
2021-03-25T15:26:45.596017Z 0 [Note] [MY-000000] [WSREP] Initiating SST cancellation
15:26:45 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.

Build ID: aa2b9a4eb56db863f004935ba64544f8e74af031
Server Version: 8.0.22-13.1 Percona XtraDB Cluster (GPL), Release rel13, Revision a48e6d5, WSREP version 26.4.3, wsrep_26.4.3

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x3d) [0x55b438c3d56d]
/usr/sbin/mysqld(handle_fatal_signal+0x373) [0x55b437dc2153]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980) [0x7f38c05dc980]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7) [0x7f38be6dffb7]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141) [0x7f38be6e1921]
/usr/sbin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x2fc) [0x55b438f4fc1c]
/usr/sbin/mysqld(+0x24a2175) [0x55b438f53175]
/usr/sbin/mysqld(srv_error_monitor_thread()+0x84b) [0x55b438ee5c2b]
/usr/sbin/mysqld(std::thread::_State_impl<std::thread::_Invoker<std::tuple<Runnable, void (*)()> > >::_M_run()+0xbf) [0x55b438dd603f]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xbd6df) [0x7f38bf1056df]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76db) [0x7f38c05d16db]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f38be7c271f]
You may download the Percona XtraDB Cluster operations manual by visiting
http://www.percona.com/software/percona-xtradb-cluster/. You may find information
in the manual which will help you identify the cause of the crash.

END OF INNODB MONITOR OUTPUT
============================
InnoDB: ###### Diagnostic info printed to the standard error stream
2021-03-25T15:26:45.595814Z 0 [ERROR] [MY-012872] [InnoDB] [FATAL] Semaphore wait has lasted > 600 seconds. We intentionally crash the server because it appears to be hung.
2021-03-25T15:26:45.595920Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: ut0ut.cc:553 thread 139839427901184
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
2021-03-25T15:26:45.596017Z 0 [Note] [MY-000000] [WSREP] Initiating SST cancellation
15:26:45 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.

Build ID: aa2b9a4eb56db863f004935ba64544f8e74af031
Server Version: 8.0.22-13.1 Percona XtraDB Cluster (GPL), Release rel13, Revision a48e6d5, WSREP version 26.4.3, wsrep_26.4.3

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x3d) [0x55b438c3d56d]
/usr/sbin/mysqld(handle_fatal_signal+0x373) [0x55b437dc2153]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980) [0x7f38c05dc980]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7) [0x7f38be6dffb7]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141) [0x7f38be6e1921]
/usr/sbin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x2fc) [0x55b438f4fc1c]
/usr/sbin/mysqld(+0x24a2175) [0x55b438f53175]
/usr/sbin/mysqld(srv_error_monitor_thread()+0x84b) [0x55b438ee5c2b]
/usr/sbin/mysqld(std::thread::_State_impl<std::thread::_Invoker<std::tuple<Runnable, void (*)()> > >::_M_run()+0xbf) [0x55b438dd603f]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xbd6df) [0x7f38bf1056df]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76db) [0x7f38c05d16db]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f38be7c271f]
You may download the Percona XtraDB Cluster operations manual by visiting
http://www.percona.com/software/percona-xtradb-cluster/. You may find information
in the manual which will help you identify the cause of the crash.

Все же написано в сообщении об ошибке.

ну с оборудованием все в порядке это ошибка вылазит уже в 3ий раз на разных серверах

тут либо конфигурация либо баг

http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html делали?

разок на одной из нод затем подняв до 4 база поломалась так что с этим параметром более не играюсь

Всем доброго вечера. Очень срочный вопрос. У нашего докер регистри упали credentials, из-за этого не можем сбилдить ни один проект, подскажите пожалуйста куда нужно логин и пароль регистри прописать, чтобы женкинс смог сбилдить

Вот такой контекст ошибки "no basic auth credentials"

Упали credentials у registry

Что

А из-за чего ещё может выдавать эту ошибку? Я так понимаю именно до регистри не могу достучаться

Ну так залогинься