там не столько чтение страдает, сколько запись.

Ну все равно больно очень. У меня чтение страдало. Я нечаянно провафлил и машинка с 36 сас дисками отдавала на чтение 3 мегабита (1!!!) в секунду. Записи не было вообще, но и заполнил я на 100%.

время на пересборку будет слишком большим чтобы рисковать с raid5

а зачем делать raid5 на весь массив?

В общем линукс плохой пример, т.к работает там под Fuse. А он там глюченый. сравнивать тогда было бы удобчно zfs на фряхе

нет, не fuse. есть zfsonlinux и там оно ядерным модулем.

время на пересборку будет слишком большим чтобы рисковать с raid5

а чем принципиально raidz отличается от raid5? ;)

а зачем делать raid5 на весь массив?

ну вот, к примеру, к 2020 году выпустят диски по 20Тб

RAID5 ведь уже не оч безопасно использовать будет?

(как и raidz1)

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

то есть чем больше размер дисков - тем больше желание уйти на raidz2-raidz3, разве нет?..

исходя из этого я назвал raidz3 неким плюсом ZFS, у которого сейчас нет других production-ready аналогов

ну, или я о них не знаю

Ну когда диски будут по 20Тб, то навернякак и интерфейс к ним будет сата25 :) и использование раид5 по опасности ничем не будет лучше/хуже использования раид5 сейчас. :)

Ну когда диски будут по 20Тб, то навернякак и интерфейс к ним будет сата25 :) и использование раид5 по опасности ничем не будет лучше/хуже использования раид5 сейчас. :)

да такой же будет))

там же HDD

Ну пойди найди сейчас IDE. А прошло-то всего-ничего :)

производство быстрых HDD (10-15 тыс оборотов) сворачивается - их заменяют SSD

Или scsi "тот самый", а не сас :)

а вот дальше HDD будут именно большими

и упор будет на низкую стоимость хранения Гб

сейчас, если не ошибаюсь, они по 12Тб

к 2020 там планы довести это до 20Тб

есть на 14Тб с Гелием

Да, по 12Тб. Но моя чуйка говорит, что с этими гелиями они все через 2-3 года уйдут в металлолом

кому zookeeper нравится?

# specify all zookeeper servers # The fist port is used by followers to connect to the leader # The second one is used for leader election server.1=192.168.215.188:2888:3888 server.2=192.168.215.187:2888:3888 server.3=192.168.215.186:2888:3888 было на виртуалках - работало, перенёс на физ машины - нет

убрать "кластеризацию" и закоментить ip не самой машины, работает, а так даже не включается

скопировал целиком, и конфиги, и рабочие каталоги?

скопировал целиком, и конфиги, и рабочие каталоги?

конфиги, инфы нужной там не было

ставил из пакетов

не может найти свой айди и падает

указан id в отдельном файле

myid

Мужики, я забываю как программировать логику. Писал пару недель приложеньки под айос, свифт конечно прекрасен, но теперь я 10 минут думаю как остановить цикл если инпут = -1 в питоне :/

break. но казалось бы, причём тут девопс?

так ему потом это разворачивать и администрировать

break. но казалось бы, причём тут девопс?

Я сначала додумал, а потом сюда написал :)

Кто использует Jenkins, вы для CD прямо продуктовые сервера делаете Jenkins slave?

докер билд, докер пуш

Я про деплоймент

Кто использует Jenkins, вы для CD прямо продуктовые сервера делаете Jenkins slave?

что это значит?

jenkins slave - билд ноды на которых происходят сборки. сервера с апп - это сервера с апп

Вот у тебя в приватном репо уже есть образа с сервисами приложения, тебе надо выкатить это в прод. Дженкинсом. Как делаешь?

docker-compose up -d --pull

Ручками?

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

Ручками?

ну пайплайн уж обычный

В общем делать продуктовые сервера jenkins slave и деплоить в прод через джобу как я понимаю не в почете

что значит продуктовые сервера jenkins slave?

можно, все что нравится)

у меня 6 славиков для обычных проектах. в разных енвах. на них происходят сборки

и все

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

это бред

и бэд практис

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

звучит как бред

т.е. так конечно вохможно

но зачем и кто это придумал?

это самый дешевый путь)

ssh?

мастер jenkins управляет слейвами тем же ssh. Считай автоматизированный ansible)

если функционал достаточный, то ваше дело)

ну как кто еще делает

просто когда инфраструктура стабильна, то да, подойдет

ну как кто еще делает

ну например нормальный путь — Jenkins обновляет роль на chef-сервере, она раскатывается chef-клиентом

ну если у тебя 1 сервис всюду нахрена всякие довески

ERROR: S client not available

ну например нормальный путь — Jenkins обновляет роль на chef-сервере, она раскатывается chef-клиентом

а чем это лучше?

более предсказуемо

keep it simple

если у тебя станет больше слейвов дженкинса, больше сборок и т.д. - нет риска запушить что-то нежелательное на продакшн

Каждой задаче - подходящий инструмент. Кажущаяся простота сегодня - завтра может стать попаболью.

при такой поставновке задачи любой вариант подходящий

сперва идем читать документацию. потом начинаем чето строить. ненаоборот

а чем это лучше?

я даже затрудняюсь объяснить

можно просто файлы на продакшене править

накой вам женкинс?

фтп и гит пул тоже крутые схемы деплоя

вы создаете нагрузку на продсервер искуственно и непредсказуемо

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

появится второй сервак прод/новый апп как будете действовать?

как откатываетесь?

кстати, да git checkout PRODBRANCH && git pull вполне рабочая схема если минимализм

ну разумнее наверное git co release-123

я даже затрудняюсь объяснить

тем, что инструмент используется по назначению

Деплой идёт на мастере кластера. На нем надо загасить старый стек, поднять новый

Все в одном файле docker-compose

backup=true docker-compose up -d --pull python test.py docker-compose up -d --pull python test.py backup=true docker-compose down python test.py

хуевая идея, поддерживаю протестующих

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

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

всякие git pull на проде - тоже бед практис

От чего Кафка работавшая месяц могла перестать работать? И жалуется на лог4 стала

От чего Кафка работавшая месяц могла перестать работать? И жалуется на лог4 стала

Не на редхате запустил прост

вот интересный ответ из стековерфлоу

Continuous Deployment can be achieved in Jenkins using Deploy to container Plugin too. Jenkins has evolved to take care of complete CI/CD pipeline and Chef integration is no more needed.

к посылу

In a nutshell, when you are building your CI/CD pipeline, Jenkins takes care of Continuous Integration and Chef takes care of Continuous Deployment.

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

как на проде, так и на дженкинсовских нодах только docker и docker-compose + git. Больше ничего не надо )