объём памяти тот же

Инцидентов с памятью замечено не было... 100+ контейнеров. В серой сети.

Я так понимаю у Виталия не балансировщик, а просто прокси

И все проекты разные

Когда ты говоришь балансировщик мы представляем динамические стейтлесс фронтенды

не, я у павла спрашивал

Которые ты то стартуешь то гасишь и все они про одно приложение

как тестировать, если нельзя полностью воспроизвести продакшен в тестовом окружении

как тестировать, если нельзя полностью воспроизвести продакшен в тестовом окружении

Ты такой вопрос задаёшь типа как купить хлеб если у тебя нет денег

Да, растарт контейнера достаточно редко.

Пытайся повторить те моменты которые критичны.

как купить точно такой же хлеб, как в другом городе из другого сырья

Например у нас девел инфраструктура тоже в 2х разных городах чтобы тестировать всякие фишки с кроссплощадками

ну вот у тебя прод на 10 серваках с 256 гигов памяти с внешними айпишникамиа

а стейдж - один проксмокс с 64 гигами памяти

и серой сетью

А что надо протестировать? Ну и конечно все понимают что проксмокса должно быть два)

А лучше три

ну смысл в том что в корне разные окружения

и никак их не приблизишь друг к другу

Нагрузочно не протестируешь

в том числе

Но логически можно

потому что базу с теми же параметрами не поднять, например

а масштабирование там нелинейное

Здесь спорить не о чем

В таких ситуациях всегда трейдофф

/

neprivet.ru

Есть тут постоянные юзеры ансибл?

да

К сожалению

К сожалению

почему к сожалению? Есть что-то лучше?

Mussh

Mussh

автоматизация уровня бардак в инфраструктуре хер кому передашь

Ты просто трус

Mussh

и собственный фреймворк на bash

Обижаешь

Перл

https://www.linux.org.ru/news/security/13320947

?

Гайз, что вы думаете про Backend-as-a-Service? По мне, проще задеплоить инстанс и написать 50 строк кода чем юзать непонятную хренобобель.

Сам спросил, сам ответил

Alex молодец

Здрасьте, девопсы

Гайз, что вы думаете про Backend-as-a-Service? По мне, проще задеплоить инстанс и написать 50 строк кода чем юзать непонятную хренобобель.

Средний разработчик пишет за день 30 строк кода. Сколько стоят полтора дня твоей работы?)

*место для фразы «Я пишу горааздо больше!»*

Средний разработчик пишет за день 30 строк кода. Сколько стоят полтора дня твоей работы?)

Бойлерплейт по 'сделать рест', 'прицепить базу' в эти 30 строк не входят.

И да, я пишу и переписываю больше.

Причем не за день а за 3-4 часа.

Да, да, естественно

Размер кодовой базы коррелирует, но не сильно с его функциональностью. Вообще сейчас строки считают или гиганты или задроты которые меряются письками, как заметил. Качество куда чаще контролируют

10 / 10 по шкале капитана очевидности

Ну это не я начал про строки кода говорить. По мне так это зашквар изначально

Гайз, что вы думаете про Backend-as-a-Service? По мне, проще задеплоить инстанс и написать 50 строк кода чем юзать непонятную хренобобель.

ну скоро будет business-as-a-service и application-as-a-service я все жду, когда будет saas-as-a-service.

пасаны

есть у кого редхат-акк?

https://access.redhat.com/solutions/2117311

поканьте че там в решении

ну скоро будет business-as-a-service и application-as-a-service я все жду, когда будет saas-as-a-service.

так 'saas-as-a-service' по логике и будет 'business-as-a-service'. Сервис для сервисов коммерческих)

так 'saas-as-a-service' по логике и будет 'business-as-a-service'. Сервис для сервисов коммерческих)

we need more *aas

говори - aas, - будь на стиле

в идеале потом про бигдату и машин лернинг затравить

ERROR: S client not available

https://access.redhat.com/solutions/2117311

Resolution Update systemd packages to at least systemd-219-19.el7_2.9 as provided by RHBA-2016:1026 If the same issues are still seen after updating, please open a support case and reference this article Root Cause From RHBA changelog: Due to a bug in handling errors when compressing journal objects, the journald service could stop working under certain circumstances, and error messages were logged. With this update, compression errors are handled properly. As a result, the described problem no longer occurs, and logs are available as expected. (BZ#1331339)

спасибо

вот уроды(с)

спасибо

да пожалуйста, не жалко погляди в сторону developers.redhat.com - зарегистрируйся - получишь доступ ко всей доке + бесплатную подписку на RHEL

вот уроды(с)

кто? ))

рх/поттеринг

я тут решил выебнуться, выпиздить сислог, засунуть всё в journald

и эпично обсеренькался из-за этой проблемы

потеребонькай и тебе полегчает

что бы не обсеренькаться

говори - aas, - будь на стиле

xaas

systemd многим хорош и удобен... но вот за journalctl - надо расстреливать тупыми пулями... особенно за то, как в RH логирование томката захерачили...

спасибо

вот что в RHBA пишут: systemd bug fix update Advisory: RHBA-2016:1026-1 Type: Bug Fix Advisory Severity: N/A Issued on: 2016-05-12 Last updated on: 2016-05-12 Affected Products: Red Hat Enterprise Linux Desktop (v. 7) Red Hat Enterprise Linux HPC Node (v. 7) Red Hat Enterprise Linux HPC Node EUS (v. 7.2) Red Hat Enterprise Linux Server (v. 7) Red Hat Enterprise Linux Server AUS (v. 7.2) Red Hat Enterprise Linux Server EUS (v. 7.2) Red Hat Enterprise Linux Workstation (v. 7) Details Updated systemd packages that fix two bugs are now available for Red Hat Enterprise Linux 7. The systemd packages contain systemd, a system and service manager for Linux, compatible with the SysV and LSB init scripts. It provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, and keeps track of processes using Linux cgroups. In addition, it supports snapshotting and restoring of the system state, maintains mount and automount points, and implements an elaborate transactional dependency-based service control logic. It can also work as a drop-in replacement for sysvinit. This update fixes the following bugs: * In an earlier version, the default value of the ForwardToSyslog parameter was changed and was by default set to "no". Consequently, the rsyslog utility was by default reading data from journal through the imjournal plug-in, in which case forwarding to traditional syslog daemons was not affected. However, if the syslog daemon read messages through the /run/systemd/journal/syslog file, forwarding to traditional syslog daemons was turned off. This update sets the default value of ForwardToSyslog to "yes" to prevent the described behavior from occurring. (BZ#1328780) * Due to a bug in handling errors when compressing journal objects, the journald service could stop working under certain circumstances, and error messages were logged. With this update, compression errors are handled properly. As a result, the described problem no longer occurs, and logs are available as expected. (BZ#1331339) Users of systemd are advised to upgrade to these updated packages, which fix these bugs.

ну т.е. ты понимаешь, да, журнал бился втихую и логи не записывались после этого

я тут решил выебнуться, выпиздить сислог, засунуть всё в journald

Журнал однопоточный. Пихая поток в 10-20к сообщений в секунду он сложиться

к счастью, там минимум на порядок меньше

это не последняя проблема с журналом

а то и 2

Ну то есть ничего с намеком на хайлоад в журнал не надо пихать

это исключительно для удобства

чтобы все логи в одном месте, да еще и с поиском/индексацией, а не с грепом прыгать

ну почему же, можно и запхнуть, а потом сразу же на сислог сервер

ЁЛКу поднимай

ELK то есть

ну или прометеус

там другой кейс

много автономных машинок

Добрый день! Подскажите сильно ли тупо заворачивать elk в кластер swarm?

много автономных машинок

как раз кейс для ELK + Grafana/Graylog2/vmware LogInsight