Мне кажется, это еще одна попытка оправдать бесполезность и рудиментарность модульной системы в Java 9. Самый большой ее недостаток — это привязка модулей к бинарным бандлам (jar) и соответвтенно лейауту проекта. Идея classpath проще и универсальней.
вот я и говорю, формулировка «по возможности не использовать forced push и rebase» применительно к мастеру должна звучать примерно так «никогда не ребазируйте ветку master, слышите НИКОГДА! „
на счет других веток — “Ребейзь @ Мощно пуш» без ограничений ну и конечно надо коллег предупреждать если кто то с этой веткой ещё работает. Всё никаких больше ограничений.
Если отменить верификацию предложения, то останется один спам. Как минимум нужно оставить фотогалерею, можно добавить скан квитации об оплате коммунальных услуг — там и площадь квартиры и фамилия владельца. Тривиальная работа не выходя из квартиры которую можно сделать с помощью iPhone не снимая тапочек за 5 минут и получить за это 2 тысячи рублей + возможность выбирать клиентов + отсутсвие необходимости пускать в дом риелторские рожи?
А как насчет верификации спроса? Много людей согласятся снять квартиру с комиссией 2 тысячи рублей вместо 20? при условии допустим загрузки свое фотографии и паспортных данных прописки?
Понятно что репутация прямого хозяина и агента будет идти совсем разным способом. Два параметра — карма ( история прошлых сделок) и рейтинг — котировка текущей сделки
Для хозяина по-сути единственное требование — доказать что он не агент. Сделать это можно при помощи скорринга/рейтинга.
1. Загрузил фото квартиры +10
2. Загрузил подробное описание +10
3. Загрузил мобильный телефон +20
3. Загрузил паспортные данные +50
4. Загрузил скан квитанции об оплате +50
5. Загрузил скан свидетельства о собственности +200
Далее проверка на уникальность.
Описание квартиры не уникальное, штраф -50
Телефон пробивается на агента штраф -100
Арендаторы пожаловались на спам штраф -10*X
Далее проверка репутации
сделка совершилась электронным образом +1 в карму
произошло подтверждение сделки в офлайне +5 в карму. ( подтверждение, например, через перевод гарантийного депозита)
Не произошло подтверждение — 1 в карму
Пришла обоснованная жалоба -1 в рейтинг.
Чем выше рейтинг, тем тем выше место в выдаче на запрос поиска предложений и тем больше открыто информации о потенциальных арендаторах.
Для агентов соответственно в основном баланс плюсов и минусов в карму, разные медальки за деньги по типу аудиторских заключений.
Для съемщиков — свой текущий скорринг и своя хистори.
Абсолютно никакого значения эта и другие даты не имеют. Имеет лишь просвещенность и образованность населения, и пока оно допускает сидение во власти тех кто сейчас, не изменится ровным счетом ничего.
Второй СССР как хочет власть, или революция как хотят некоторые одинаково никому и никак не помогут, а сделают только хуже.
Нужно контролировать исполнение законов, искать коррупцию, подавать жалобы, устраивать показательные порки чиновников в СМИ и соц. сетях и так далее. Вот единственный нормальный путь правого государства — все прочее лишь меняет фон, а суть оставляет как и прежде.
Ну а вы сидите и ждите еще год. Потом другой даты, потом третьей, всегда что-нибудь найдется.
Так совпало, что я сейчас изучаю эту же тему со связкой Ansible+Consul+Docker Swarm. Вы используете для service discovery при построении кластера Docker Swarm подключение к Consul первый IP адрес в датацентре. В таком случае, при сбое этой ноды кластера Consul, у вас развалится кластер Docker Swarm. Это проверено на личном опыте. Правда я кластеризую еще и роль Docker Swarm Manager.
В issue репозитария Swarm на гитхабе разработчиков просили дать возможность указывать несколько адресов нод Consul, но это невозможно из-за ограничение go библиотеки клиента Consul, которая используется в коде Swarm. В итоге обсуждений пришли к решению использовать в качестве адреса подключение consul.service.consul. Если указать в качестве дополнительных DNS адресов на холстах в датацентре адреса нод кластера Consul, то в вашем случае consul.service.dc1.consul вернёт вам как раз «здоровые» ноды кластера Consul.
К сожалению я не успел проверить отказоустойчивость этого решения, так как в данный момент борюсь со связкой Ansible+VMware vSphere.
Посмотрите в сторону weave или того же consul'а — у них есть встроенные dns-сервера, которые получают данные о сервисах не от самих сервисов, а слушая docker-сокет, что избавляет от необходимости самому делать обновление DNS и обработку, например, падения контейнера.
У себя я тоже полностью отказался от связывания и сейчас использую weave — доволен им: во-первых, есть внутренняя сеть контейнеров, независимая от внешней топологии и позволяющая связывать разнородные сети, в том числе, разные датацентры; во-вторых, есть надежное автообновление DNS при старте-остановке контейнера, которое позволяет реализовать красивую автобалансировку.
в основном конфиге nginx. Можно делать и более сложные варианты. К примеру у меня такой был: «все запросы на https редиректить на http кроме некоторых адресов»:
Интересует вопрос миграции подов. Допустим система управления приняла решение разгрузить одну из нод, и должна выселить с ноды 30% подов. Как это возможно реализовать? Пока расматриваю 2 варианта:
Переводим ноду в статус unschedulable и запускаем rolling-update для репликейшен контроллеров которые имеют поды на необходимой ноде. Таким образом RC заменит поды по очереди, и стартанет их уже в новом месте
Настроить жеский контроль по лейблам, и так же ролинг апдейтом перемещать поды с ноды на ноду
Kubernetes, сам по себе, не решает проблему связи с пользователем.
Очень даже решает. Вы можете запустить Pod с опцией hostNetwork: true. В результате порты будут доступны не на виртуальном динамическом IP, а снаружи. Конфиг выглядит примерно так:
Тут важны два момента. Во-первых, мы ограничиваем, на каких нодах запускать nginx (только на тех, которые мы пометили как frontend=true), а во-вторых, порты 80 и 443 будут доступны снаружи (hostNetwork: true).
Потом можно снаружи какой-нибудь Cloudflare прицепить, чтобы внешний трафик проксировал на эти машины, и получится нормальный отказоустойчивый фронтенд.
Смысл контейнеров заключается в бинарных апдейтах. В вашем случае это удобно для выкатывания обновлений php. В норме у вас app сервер, помимо php, будет содержать всякие утилиты типа imagemagic и прочие зависимости системы которые, могут уходить глубоко в libc.
Каждый раз когда вы выкатываете обновление обновление на конфигурацию app сервера вы рискуете получить отличающееся состояние. Докер гарантирует, что обновления будут идентичными.
Но статья-то про кубернетис, а это следующий шаг после контейнров — scheduled deployments. Тут две радости — во первых удобно следовать infrastructure as code, во вторых масштабировать систему очень приятно — говоришь я хочу еще 10 этих контецнеров и через 5 секунд они работают.
Предполагается делать это так. Вы ставите на все машины кластера GlusterFS, который поддерживает нужный уровень избыточности данных. Затем, когда контейнер запускается, у него создаётся volume, «смонтированный» в один из каталогов GlusterFS. В результате, все инстансы вашего приложения имеют доступ к одной и той же файловой системе без лишних телодвижений.
Сбор логов — это отдельная задача. Надо настроить nginx (и все другие контейнеры) писать логи на stderr, потом их нужно чем-то собирать со всего кластера и уметь по ним поиск делать. Говорят, Fluentd + Elasticsearch хорошо работают.
Думаю, было бы неплохо, если бы кто-то сделал сервис по типу Steam, только немного по-другому. Человек покупает право смотреть фильм, и может скачать его в любом качестве с любой озвучкой с любых торрентов. Факт покупки регистрируется в сервисе. Можно даже делать «официальные» торрент-трекеры, которые будут проверять факт покупки. Группы, делающие локализованную озвучку, могут продавать ее отдельно, как дополнение к фильму. Сейчас все это есть в каком-то виде, но распределено по разным сайтам разных производителей контента. Просто нужен сервис, который позволит это делать удобно, централизовано и относительно дешево.
Всю жизнь для подобного использовали:
а для lookup-а сервисов — ServiceLoader.
Мне кажется, это еще одна попытка оправдать бесполезность и рудиментарность модульной системы в Java 9. Самый большой ее недостаток — это привязка модулей к бинарным бандлам (jar) и соответвтенно лейауту проекта. Идея classpath проще и универсальней.
И его соседа в нормальной стране также за судят за софт, написанный на рабочем месте.
на счет других веток — “Ребейзь @ Мощно пуш» без ограничений ну и конечно надо коллег предупреждать если кто то с этой веткой ещё работает. Всё никаких больше ограничений.
А как насчет верификации спроса? Много людей согласятся снять квартиру с комиссией 2 тысячи рублей вместо 20? при условии допустим загрузки свое фотографии и паспортных данных прописки?
Для хозяина по-сути единственное требование — доказать что он не агент. Сделать это можно при помощи скорринга/рейтинга.
1. Загрузил фото квартиры +10
2. Загрузил подробное описание +10
3. Загрузил мобильный телефон +20
3. Загрузил паспортные данные +50
4. Загрузил скан квитанции об оплате +50
5. Загрузил скан свидетельства о собственности +200
Далее проверка на уникальность.
Описание квартиры не уникальное, штраф -50
Телефон пробивается на агента штраф -100
Арендаторы пожаловались на спам штраф -10*X
Далее проверка репутации
сделка совершилась электронным образом +1 в карму
произошло подтверждение сделки в офлайне +5 в карму. ( подтверждение, например, через перевод гарантийного депозита)
Не произошло подтверждение — 1 в карму
Пришла обоснованная жалоба -1 в рейтинг.
Чем выше рейтинг, тем тем выше место в выдаче на запрос поиска предложений и тем больше открыто информации о потенциальных арендаторах.
Для агентов соответственно в основном баланс плюсов и минусов в карму, разные медальки за деньги по типу аудиторских заключений.
Для съемщиков — свой текущий скорринг и своя хистори.
Простор для творчества — огромный.
Второй СССР как хочет власть, или революция как хотят некоторые одинаково никому и никак не помогут, а сделают только хуже.
Нужно контролировать исполнение законов, искать коррупцию, подавать жалобы, устраивать показательные порки чиновников в СМИ и соц. сетях и так далее. Вот единственный нормальный путь правого государства — все прочее лишь меняет фон, а суть оставляет как и прежде.
Ну а вы сидите и ждите еще год. Потом другой даты, потом третьей, всегда что-нибудь найдется.
В issue репозитария Swarm на гитхабе разработчиков просили дать возможность указывать несколько адресов нод Consul, но это невозможно из-за ограничение go библиотеки клиента Consul, которая используется в коде Swarm. В итоге обсуждений пришли к решению использовать в качестве адреса подключение consul.service.consul. Если указать в качестве дополнительных DNS адресов на холстах в датацентре адреса нод кластера Consul, то в вашем случае consul.service.dc1.consul вернёт вам как раз «здоровые» ноды кластера Consul.
К сожалению я не успел проверить отказоустойчивость этого решения, так как в данный момент борюсь со связкой Ansible+VMware vSphere.
У себя я тоже полностью отказался от связывания и сейчас использую weave — доволен им: во-первых, есть внутренняя сеть контейнеров, независимая от внешней топологии и позволяющая связывать разнородные сети, в том числе, разные датацентры; во-вторых, есть надежное автообновление DNS при старте-остановке контейнера, которое позволяет реализовать красивую автобалансировку.
map "$request_uri" $skip {
default 0;
"test.php" 1;
}
в основном конфиге nginx. Можно делать и более сложные варианты. К примеру у меня такой был: «все запросы на https редиректить на http кроме некоторых адресов»:
map "$server_port:$uri" $https_redirect {
default 0;
"443:/clean/RbkMoneyCallback" 0;
"443:/robots.txt" 0;
"~^443:.+$" 1;
}
Теперь достаточно в одном месте дописывать эти адреса и не копаться в if-ах разных location-ов.
Тут важны два момента. Во-первых, мы ограничиваем, на каких нодах запускать nginx (только на тех, которые мы пометили как frontend=true), а во-вторых, порты 80 и 443 будут доступны снаружи (hostNetwork: true).
Потом можно снаружи какой-нибудь Cloudflare прицепить, чтобы внешний трафик проксировал на эти машины, и получится нормальный отказоустойчивый фронтенд.
Каждый раз когда вы выкатываете обновление обновление на конфигурацию app сервера вы рискуете получить отличающееся состояние. Докер гарантирует, что обновления будут идентичными.
Но статья-то про кубернетис, а это следующий шаг после контейнров — scheduled deployments. Тут две радости — во первых удобно следовать infrastructure as code, во вторых масштабировать систему очень приятно — говоришь я хочу еще 10 этих контецнеров и через 5 секунд они работают.