LINUX.ORG.RU

Cloud-разработка в Chrome OS на ASUS Chromebit и Kubernetes+CoreOS

 , , ,


16

5

У меня давно настроен Kubernetes+CoreOS на одной машине и это позволяет мне экспериментировать с разработкой распределенных приложений дома и запускать разные сервисы вроде торрентов и транскодинга в условиях жесткой изоляции среды и ресурсов.

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

  • Будет глобально доступна с любой машины в мире без установки софта кроме браузера.
  • При работе с другого континента не будет ощущаться задержка при печати как было бы в vim+tmux. mosh скорее всего бы не решил проблему с vim.
  • Глобально доступны по HTTPS веб-приложения запущеные в этой среде
  • В Linux среде где запускается разрабатываемое приложение можно заменить дистрибутив на другой за несколько минут, но сохранить home.

Чтобы эксперимент был чистым все это тестируется на ASUS Chromebit со стоковой ChromeOS, 2 ГБ памяти и ARM Rockchip Quad-Core RK3288C, которая размером с большую флешку и воткнута в телевизор LG 49LB550V. Потому шрифты могут быть чуть больше чем обычно, чтобы было лучше видно на телевизоре. Устройство очень маломощное, но работает быстро потому что в ChromeOS нету дискового swap, только RAM+zRAM и если что-то не влезает, то выгружается.

Скриншоты

  • Редактор Codiad в полноекранном режиме. В принципе можно установить любой другой, но для обычного редактирование текста он подходит. Если найду такой, который потребляет мало памяти и умеет режим vim, поставлю его.
  • tmux. Вот так выглядит контейнер для разработки. Он совершенно отдельный от Codiad и я могу менять в нем дистры простым редактированием Dockerfile. В него и в Codiad примонтирован один и тот-же каталог с исходным кодом. При смене контейнера home тоже сохраняется. В данном случае в контейнере последняя версия Ubuntu, но ядро как всегда остается хостовым от CoreOS. В контейнер заранее установлены средства разработки на C++, Go, Python, NodeJS.
  • Caddy, который вы видели запущеным в контейнере. Интересная часть заключается в том, что для него создается виртуальный хост, создается Let's Encrypt сертификат и производится авторизация. Это умеет делать и сам Caddy, но он тут просто для демо. Суть в том, что в данном случае это будет делаться на уровне nginx фронтенда для любого приложения открывшего порт 8080 в контейнере
  • tmux+vim. Если работать не издалека, то вполне можно просто пользоваться tmux+vim. Плагины на него устанавливаются в home и в основном продолжают работу при смене дистра, кроме тех, которым нужна перекомпиляция.
  • Внутренности. Это Kubernetes Dashboard. В ней вы видите некоторые из упомянутых выше контейнеров и еще много чего. Для временных изменений некоторые параментры контейнеров можно менять прямо в UI, но лучше конечно через файл конфигурации.

Изначально CoreOS машина разворачивается сама по iPXE на голый диск. Если система уже была установлена, то она просто загружается. После этого по SSH необходимо загрузить ключи и некоторый набор базовых сервисов Kubernetes. Теперь кластером можно пользоваться удаленно через kubectl. Я запустил там локальный docker реестр, потому вы видите localhost в названии некоторых контейнеров. На моей машине различные сервисы работают на Alpine Linux, Ubuntu или CentOS в зависимости от того, на чем было проще настроить конкретное приложение. Если разницы нету, то я использую Alpine, так как тогда контейнеры наиболее компактны.

Цепочка загрузки такая

  • BIOS
  • PXE
  • iPXE
  • Ядро CoreOS
  • systemd
  • Docker
  • Kubernetes
  • Сервисы из публичных образов и локальный Docker реестр
  • Сервисы из локального Docker реестра

В качестве сервера использую старый Dell ноутбук с Core i7-2630QM, 8GB RAM и сломаной батареей, ибо нечего ему пылиться с таким процессором.

Если я захочу подключить второй сервер, то мне нужно сделать два действия: сделать для второго сервера облегченный конфиг без части Kubernetes демонов и придумать как монтировать диски удаленно. Пока что персистентные каталоги монтируются в хост систему, что не будет работать если сервисы будут случайно мигрировать между машинами. Но если я это сделаю, то полностью програмная виртуальная сеть на flannel будет работать полностью прозрачно и контейнеры на разных будут общаться друг с другом так же просто как и раньше. Из того что можно настроить дома поддерживаются GlusterFS+Heketi, Ceph и NFS

Среди дополнительных удобств на сервере есть связка Transmission+Plex, интерфейсы которых тоже доступны глобально. Потому я могу пойти в гости, поставить torrent дома с телефона, а потом транскодированый и оптимизированый фильм можно посмотреть на телевизоре например через Chromecast, AppleTV, PS4, XBox, Android, Windows Phone или другой способ отобразить браузер с компьютера на телевизор.

В качестве заключения скажу что мне понравился такой способ настройки домашнего сервера. Использование Docker контенеров позволяет уравнять в легкости настройки опакеченый софт из дистрибутивов и софт, который устанавливается скриптом сборки на github. Они оба могут быть завернуты в контейнер на любом дистрибутиве и потом когда более не нужны могут быть аккуратно удалены. Kubernetes очень облегчил работу с виртуальными хостами, шифрованием, перенаправлением портов, изоляцией ресурсов, перезапуском упавших сервисов и проверкой их здоровья.

>>> Просмотр (1920x1080, 1069 Kb)

★★★★★

Проверено: JB ()
Последнее исправление: vertexua (всего исправлений: 3)
Ответ на: комментарий от vertexua

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

dima1981
()
Последнее исправление: dima1981 (всего исправлений: 2)
Ответ на: комментарий от vertexua

Вот-вот, я даже не стал читать эту простыню из слов, ибо читать невозможно :)

Deleted
()

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

А базу данных как шаришь?

loz ★★★★★
()
Ответ на: комментарий от loz

Ну просто пихаешь в докер контейнер. Если надо просимулировать распределенность - делаешь несколько pods. Допустим они получат адреса 10.2.0.1, 10.2.0.2. Потом декларируешь сервис и внутри програмной сети созданой Kubernetes будет доменное имя для БД и round-robin между pods. DNS будет указывать на в основном стабильный адрес в 10.3.0.0/16 подсети, например 10.3.0.1.

Если нужны пароли или ключи, то они в Kubernetes кладутся в «секреты» и могут быть примонтированы к контейнерам где бы они не находились. Сами контейнеры могут видеть только то, чо им примонтировали в конфигах Kubernetes

vertexua ★★★★★
() автор топика
Последнее исправление: vertexua (всего исправлений: 1)

Классно. Надеюсь, будущее десктопного GNU/Linux будет именно таким, а не KDE/GNOME идиотия.

EXL ★★★★★
()
Ответ на: комментарий от Shaman007

почему нет :)

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

dima1981
()
Последнее исправление: dima1981 (всего исправлений: 1)
Ответ на: комментарий от EXL

Как бы теоретически это может быть даже своеобразным дистром, который бы составил в чем-то конкуренцию FreeNAS и им подобным

vertexua ★★★★★
() автор топика

Делаю подобное на пачке виртулок, что бы всякие эксперименты с pet-project-ами делать

DiKeert ★★
()
Ответ на: комментарий от vertexua

спасибо. а вот опубликовать как ты настроил торрент под кубернетс есть желание?

Nurmukh ★★★
()

Я не согласен зависить от кокогото Модера. И так на разных инет ресурсах банят как хотят и кого хотят.А тут ещё и Ось в облаке.Да ну это нах. Чуть что не понраву Модератарам или РосКомНадзору и комп можно выкинуть на помойку. Хуюшки им всем

debian000 ★★
()

Ай молодец, за ChromeOS, CoreOS и Kubernetes от меня особый респект.

dvrts ★★★
()
Ответ на: комментарий от vertexua

8 ГБ вполне нормально для VM

У меня тоже некоторое время ноутбук со сломанным экраном в качестве сервака на шкафу работал. По параметрам гораздо скромнее (acer aspire one с AMD C60 и 4GB ), но я там и виртуалку в w2k12 поднимал с KVM.

Сейчас тоже перевожу внутренние сервисы в docker (gitea/confluence/seafile), только nginx по-прежнему на хосте. Пока без kubernetes.

Что используешь для бэкапа? Я раньше crashplan использовал (его, кстати, тоже в докер можно запихать), сейчас думаю над вариантом с duply + yandex.disk, но там минус что нужно локально место выделять.

gorilych ★★
()
Ответ на: комментарий от gorilych

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

vertexua ★★★★★
() автор топика
Ответ на: комментарий от vertexua

Вдохновился этим постом и таки перекатил свой домашний сервер с Debian Wheezy на CoreOS и закатал используемые приложения в контейнеры. Работает на 10/10, заодно «пощупал» наконец-то Docker.

no1_tx
()
Ответ на: комментарий от no1_tx

Если используешь CoreOS, но без Kubernetes, то там есть встроеная штука, которая называется fleet. fleetctl - это как systemctl, но работает через встроеный etcd и будет работать запуская юниты по кластеру из многих машин. Оно просто запускает systemd юниты и ничего не знает о докере (хотя доставляет эти юниты по сети), так что это два разных инструмента. Если у тебя будет docker registry свой, то оно может образы на любую машину вытягивать по сети на любую машину где fleet решит запустить юнит. Если машина дохнет, то fleet перезапускает все в другом месте сам.

У тебя наверное всего один сервак, но все равно это все очень интересно пощупать.

Вот первое видео из серии с полным описанием настройки и обьяснением как работает связка CoreOS+Fleet

https://www.youtube.com/watch?v=wxUxtflalE4

vertexua ★★★★★
() автор топика
Последнее исправление: vertexua (всего исправлений: 2)
Ответ на: комментарий от vertexua

Ага, спасибо. Docker registry еще не раскуривал, но если я его запилю - там контейнеры будут гулять с уже заданными параметрами вроде Volume и Publish или они будут на нодах по новой разворачиваться из моих образов и придется всё это прописывать в unit-файлы?

//понимаю, что мой вопрос скорее всего уже освещен в видео, но я пока еще не смотрел и только это пока отторгает меня от «ощупывания»

no1_tx
()
Ответ на: комментарий от Nurmukh

я тут недавно научилась деплоить kubernetes через kargo

это по сути набор ansible playbooks для красивого деплоя multi-master, multi-node-кластера с ha для etcd, calico для сети и т.п.

рекомендую

https://github.com/kubernetes-incubator/kargo

пишешь свой inventory/inventory.ini и

ansible-playbook -i inventory/inventory.ini cluster.yml

alpha ★★★★★
()
Ответ на: комментарий от alpha

а для локальной работы есть minikube

там вообще скачал, сказал ./minikube start

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

alpha ★★★★★
()
Ответ на: комментарий от no1_tx

Не, суть docker registry в том чтобы когда ты запускаешь

docker run -it my-company/my-image, то my-company/my-image брался из твоего личного репа (я сейчас не о Github, а о Docker регистре), а не из Docker Hub например.

Там просто в бинарной форме лежат слои файловой системы из которых состоит образ

vertexua ★★★★★
() автор топика
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от alpha

образ вмки

Не спортивно. И походу тормозно если там какой-то qemu. Ведь там таки не контейнеры как я понимаю чтобы сами «вмки» поднять.

vertexua ★★★★★
() автор топика
Ответ на: комментарий от vertexua

неспортивно - это да, с kargo сильно веселее, можно проследить что и как происходит

вмка там ровно одна, а дальше в неё уже внутри контейнеризованные сервисы. То есть это такой вырожденный кластер в одну ноду, всё в себе.

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

Но для первого знакомства, поиграться с API и подергать kubectl вполне интересно.

alpha ★★★★★
()

терминал в браузере - нечто новое.

В качестве сервера использую старый Dell ноутбук с Core i7-2630QM, 8GB RAM и сломаной батареей, ибо нечего ему пылиться с таким процессором.

чего только нет у богатых людей ^_^. имхо проще поставить пару софтин, чем проделывать подобную настройку сервера.

NextGenenration ★★
()
Ответ на: комментарий от NextGenenration

Я научился настраивать Kubernetes. И когда он уже настроен, то на нем пара софтин ставится еще проще )

vertexua ★★★★★
() автор топика

vertexua

Добрый день. я на домашнем сервере под виртуалкой поднял кластер coreos. поверх кластера kubernetes. возникло два вопроса:

1 - узел кластера может быть либо мастером, либо воркером. как объединить обе роли в одном сервере?

2 - как прокидывать айпиадреса наружу, чтобы был доступ к сервисам kubernetes?

заранее спасибо

Nurmukh ★★★
()
Ответ на: комментарий от Nurmukh

узел кластера может быть либо мастером, либо воркером. как объединить обе роли в одном сервере?

Можно сделать мастером, а потом убрать --register-schedulable=false. В гайдах он обычно стоит у мастера, но если его убрать или лучше явно поставить в true, то контенеры начнут запускаться на мастере тоже.

как прокидывать айпиадреса наружу, чтобы был доступ к сервисам kubernetes?

Сначала нужно прокинуть порт из контейнера. Потом нужно зарегистрировать Service обьект в Kubernetes. А вот теперь два варианта.

Если нужно прокинуть какой-то TCP (обычно не HTTP), то можно в обьекте ports у сервиса использовать поле nodePort. Например если у тебя обьект порт есть в сервисе, и у него есть следующие свойства, то вот что это будет значить

  • port: 5269 // при присоединении из внутренней (flannel) сети к этому сервису, сервис будет доступен по этому порту
  • targetPort: 5269 // этот сервис редиректит на этот порт в pods
  • nodePort: 5269 // при присоединении из внешней сети к ЛЮБОМУ узлу кубернетеса по этому порту, будет происходить редирект на этот порт этого сервиса.

Второй вариант - когда у тебя HTTP. Тогда смотри Ingress ресурсы. Тогда nodePort для 80 и 443 регистрируется раз и навсегда для самого ингресс-контроллера, а он уже будет обеспечивать например виртуальный хостинг для твоих сервисов. Тоесть если у тебя кубернетес кластер (любое подмножество узлов) доступен по example.com, то через ингресс его можно научить редиректить на разные сервисы если кто-то зайдет на foo.example.com и bar.example.com. Безопасность может быть настроена раз и навсегда для всех этих доменов на самом ингрессе, например авторизация. HTTPS делается тоже на ингрессе автоматически для всех сервисов через Let's Encrypt если установить в кластер Kubernetes Lego.

vertexua ★★★★★
() автор топика
Последнее исправление: vertexua (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.