Юрий Ярош

1 - гораздо короче цикл разработки, хорошо проработан инструментарий и конкретные подходы к разработке, по сравнению с JVM языками и Rust / Python
2 - надо уметь в кодогенерацию, очень много кодогенерации... потому вопросы все решаются "шаблонно" и зависят от количества уже существующих наработок и качества выработки подходов к разработке
3 - быстрое TDD, относительно большое количество стабильных библиотек аналогов которых нет в других языках, есть подходы типа zero-alloc (0lloc) и gc-less конкретно для highload'a (стоит глянуть как работает fasthttp и как там происходит аллокация, на пулах и с ресайзом слайсов), в случае с JVM надо там во всякие disruptor'ы уметь и прочий морально устаревший бред... jmh не умеет нормально полить аллокации и мониторинг GC тоже местами поверхностный, а объектная модель незаурядно раздута (привет Project Panama).
С недостатков - монолитный и топорный Runtime, а 99% поделок сообщества и правок просто обесцениваются и игнорируются... тяжко, например, там какой-нить F-Stack прикрутить и т.д. без допилки компилятора и рантайма. Хотя в случае с JVM это почти невозможно. Про Python/Rust не могу сказать.

Открываем шаблон (ссылка не поститься потому что содержит слово proxy)

github.com/helm/charts/blob/master/stable/stolon/templates/proxy-service.yaml

Cмотрим эту самую 15 строку

{{- if (or (eq .Values.proxy.service.type "ClusterIP") (empty .Values.proxy.service.type)) }}

Видим что оно ожидает либо пустой тип либо СlusterIP либо LoadBalancer.

Меняем

proxy:
  service:
    type: "ClusterIP"
    clusterIP: "10.233.60.152"

или

proxy:
  service:
    type: "LoadBalancer"
    loadBalancerIP: "10.233.60.152"

Уметь поднять

- Rancher на RKE (debian или rancheros)
- Рабочий кластер на k3os под Calico
- Vault Operator
- kube-prometheus
- Velero backups
- Rook Ceph Minio
- consul-k8s под Ambassador
- skaffold & telepresence
- Argo CI/CD (https://argoproj.github.io/)
- Gitea (https://gitea.io)
- gitlab
- Weave Scope & Net

Желательно уметь писать кастомные Kubernetes Controller'ы под Operator Framework.

Желательно научиться ещё в DBA и в
- wal-g
- stolon
- pg_pathman
- pg_rewind
- pg_repack

под PostgreSQL.

А также не помешает познакомиться с жизненным циклом HA Cassandra / ScyllaDB и Kafka.

Вообще есть Terratest Inspec Kitchen (для извращенцев) ServerSpec (для рельсоводов) Bats (для олдфагов).

Типа так

Обычно и сам использую TerraTest / Bats / Inspec... Chef'ные поделки от лукавого.

Вы используйте Rancher в production?

Да.

Управляющий сервер, не отказоустойчив?

Отказоустойчив.

Что будет если он умрет (вот совсем)?

Ничего.

Просто отвалятся метрики и Node Pool'ы - при перезапуске может не подхватить состояние и нужно будет ручками ноды "потерянные" в Node Pool'e добавить/убрать.

На рабочее приложение это особо сильно не повлияет, если у вас в пуле больше 3ёх машин... а так то может лечь.

Не нашел консоли в вебе, нужно проваливаться в exec контейнера?

Kubectl соответсвующего класстера запускается... с него уже можно стучаться хоть куда.

чем вы пользуйтесь для развертывания и управления кластерами k8s?

Сами пилим аналог ранчера на стероидах, с шахматами и поэтессами...

К сожалению, безопаснее всего через Operators Framework и Skaffold дёргать соответствующие чарты и деплоить ...

Соответственно Ваше приложение будет оператором, а сервисы под капотом сугубо атомарными и изолированными, немного рекламы.

Само приложение лучше накатывать не через CI а настроить нормальное СD на Argo или Spinnaker. Argo более гибок...

совсем не следит за состоянием самих нод - если одна ООМится

Уже пофиксили через HEALTHCHECK / STOPSIGNAL в Dockerfile. Да и давно работает стандартый OOM.

Как я понимаю, эту проблему решает кубернетс - это некая надстройка(??)

Нет, кубер это в первую очередь средство управления ресурсами, причём любыми...
Так как есть CRD и custom controller'ы, c Operator Framework'oм.

ComCast, например, управляет железом для стриминга и соответствующим SDN полностью в рамках K8S.

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

Пока ничего лучше Operator Framework поверх Argo / Spinnaker не знаю.

Есть для "простых" - rancher.

Rancher сам по себе только деплоит Kubernetes класстер на пачку серверов, мониторит его, а также позволяет немного бэкапить, накатывать простенькиие Helm Chart'ы.

Потому в 99% случаев всё сводиться к "Terraform'у ручками" и к самописным Custom Node Driver'ам.

Вот что реально можно и стоит автоматизировать на Rancher'e так это Cluster Nodes Autoscaling, когда ранчер сам в Node Pool добавляет / удаляет машин по текущим метрикам и делает соответствующий rebuild всякого...

Практической пользы от rancher'a в случае использования Kubernetes as a Service хостингов не много, если часто не приходиться клонить / обновлять / удалять пачки кластеров и переносить всё с одного хостинга на другой, ну там с подвала в GCP / AWS и наоборот.

Мне хочется избавиться от проблемы докера (особенно когда сворм все запихивает на одну оставшуюся ноду), и попрпобовать что-то новое.

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

Пробуйте Kata Containers под gVisor в Kubernetes (получается довольно секурно).
Сам Kubernetes можно запустить например не в докере а в Nomad'e (так делает Sony).

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

Кроме ранчера не видел больше ничего ...
Сам пишу им конкурента сейчас.

Проблема не в наличии книги а в том что само API кубера довольно изменчиво и каждую минорную версию половина кубера устаревает... потому надо научиться азам, смотреть на существующие операторы и писать что-то похожее на Operator Framework / Operator SDK, пробовать на go в кастомные контроллеры и с разными стратегиями деплоя в Argo / Spinnaker.

Вообще такое называется Air Gap деплойментом и вполне возможно с помощью Rancher / RancherOS / k3os.

Просто выкачиваются в архив образы релиза парой скриптов 1, 2. Это достаточно хорошо описано в документации.

Потом этот архив импортируется на DockerOS и можно поднимать k3os хосты и менеджить их в ранчере...
Сам ранчер желательно допилить под потребности такого проекта.

Поддержка у ранчера достаточно хорошая.

Там есть проблемы...

Надо костыли типа Slony или Stolon
Что бы миграции "расползлись" по кластеру как-то.
Для миграций можно liquibase c местным formatted SQL'ем.

Накатывать можно чем-угодно.

В принципе Postgres-XL уже потерял свою актуальность PG11 + stolon / pg_pathman хватает с головой, ещё можно Citus, но имхо он слишком толстый. Если надо map/reduce'ить - лучше план вручную написать.

Сам по себе react-native очень сырой и кривой в различных вариациях - без нативной разработки и ковыряния issues'ов в github'e в нём совсем никак. Без знания Obj-C / Swift'a и Java/Kotlin лезть не советую, иначе будут глупые вопросы по типу: "а где мне найти нормальную либу для анимаций в 60fps ?", ответом будет: "Взять и написать".

Сам по себе RN под iOS был написан на C C++ Obj-C и Obj-C++ в разное время и разными людьми, без тестов.
В целом ощущение что "собрали на скорую руку из говна и палок".

Да, у него есть отдельный графовый Store, который умеет выполнять merge/split данных на графах.
GraphQL Schema Stitching осуществляется посредством Viewer контракта, но он, естественно совсем недокументирован.

Сейчас имеет смысл использовать Apollo2 вместо relay modern (1.0+).

Вышел Apollo2, так что вопрос отпал сам собою...

Состояние в redux'e под GraphQL хранить - очень плохая затея, так как нужно сразу же оформить middleware для merge/split операций на графах, а у нас обычно разработчики "ниасилят" такое.

Да, в relay modern (1.0+) можно запилить redux в качестве стора через Environment.

Уже вышел Apollo2 - так что не вижу ничего сложного.
На самом то деле проблема больше в корявом бэкенде - разработчики не умеют писать Schema мапперы что бы замапить схему реляционной СУБД на схему GraphQL API и привязать соответствующие ААА сервисы.

В этом плане советую глянуть join-monster и postgraphql.
мб заопенсорсю свой маппер когда-нить.

node --v8-options | grep "in progress"

В принципе есть поддержка es6 модулей через --harmony флаг, но лучше использовать полифилы или SystemJS.

Можно поставить через chocolatey nodejs а далее плясать, как обычно, через npm

@powershell -NoProfile -ExecutionPolicy Bypass -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin

choco install nodejs

npm install -g stylus
npm install -g nib

Поясню на пальцах левой ноги.
Есть тот же bladeRF, и без проблем можно поднять свою базовую станцию на том же OpenBTS'e, к примеру вот так. Если лет 6-8 тому назад это было просто мистикой, и подобное оборудование стоило несуразных денег, то сейчас это обходится всего лишь в раёне 500-700$ за экземпляр.

Если самому собирать на ПЛИСках - будет конечно дешевле, в рознице тот же AD9364 обходится в 130 долларов, а AD9361 с двумя RX/TX модулями - около 180 долларов плюс ПЛИСка типа Spartan6/Cyclone4 30$ и обвес в 50-60$ потолок...

Дыры в GSM'e есть и будут, фиксить их не выгодно, даже тем же органам.

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

Да, сугубо с технической точки зрения, подобное баловство, с возможностью записи звонков/СМС при подключении к поддельной базовой станции, нынче очень даже реально, и не раз было замечено в пост-совковом пространстве, не знаю как там в РФ, а в Украине с этим совсем мрачно.

Я бы не сказал что это паранойя потому что сам пробовал пару лет назад такое проворачивать - вполне реально и зависит от кривизны рук и беспечности мобильных операторов.

yii1 морально устарел
yii2 дружит с PHP5.4 и вот только-только допиливается поддержка PHP7
В phalcon'e 2.1 уже есть рудиментарная поддержка РНР7, осталось только подаждать месяц-второй пока допишут.
В Symfony3 (тадам уже 3!) есть полная поддержка РНР7 ещё с предыдущего года.

Если начинать переписывать что-то на что-то РНРшное - нужно понимать что сейчас допилят РНР7 решения и всё автоматом устареет, или же отвалится из-за отсутствия обратной совместимости.

Желательно брать сразу симфонию и Sonata-Project бандлы - это будет идеальной заменой тому же WP.

Даже в случае с PostgreSQL'ем, СУБД имеют достаточно уровней инкапсуляции позволяющих разделять несколько табличных пространств и схем в рамках одной и той же базы данных.

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