G
logo
Glow labs
Создание распределенной ОС для людей
G
logo
1
читатель
5 000 ₽
всего собрано
Glow labs  Создание распределенной ОС для людей
О проекте Просмотр Уровни подписки Фильтры Статистика Обновления проекта Контакты Поделиться
Все проекты
О проекте
Основной недостаток текущих решений как, например, Kubernetes это соотношение ценность/сложность. Все эти pods, kubelets, groups, tons of error prone configuration, десятки демонов и все же он не решает ни одной из простейших нужд:.
  1. Прозрачный service discovery 
  2. Динамическая реконфигурация
  3. Агрегация логов
  4. Простой мониторинг

С моей точки зрения для простого и полнзного PaaS нужны:
1. Приложение описывается одним простым YAML хранящемся в центральном репозитории
— name имя YAML файла
— provided services as a list of ports (TCP/UDP)
— required services as a list of application: port—>local port entries

— image name and version in the artifact repository

— optional list of tags to classify the application

— optional config file location, the PaaS will update it atomically in real-time

2. An instance of application gets all of required services mapped to a distinct ports on loopback interface. A config file «magically» appears on the hardcoded path. Developer box, dev cluster, staging cluster, production cluster — all environments look the same to the app instance. Packaged as a container or not, started under debugger or not etc. it behaves the same.

3. The port mapped on loopback are listened by a smart proxy that balances traffic, handles (partial) outages of target application, service discovery, and retries with fallback policy.

4. Application instance logs to stdout or stderr, it gets forwarded to wherever appropriate.

5. Apps in the cluster are identified by name of the image + version of the image + # of instance.

6. External systems are exposed to the cluster apps just like another app and proxies work the same.

7. Exposing apps to the world is done again with a list of a simple YAMLs stored in a centralized config repository.

8. Since all communication goes through smart proxies, they accumulate metrics on all network events — connects/disconnects/traffic/request timings (for HTTP and other well-known protocols).

9. Deployment is simple process — there is a YAML for each app instance that is stored in the central configuration:

— application name

— cluster node to run at

— instance id, positive number (optional)

Stopping an app is simply deleting a file (or moving elsewhere).

This takes just enough of opinionated convention and leaves a bit flexibility to get the following:

1. High developer productivity — works on your box the same as in the cloud.

2. Free of most configuration headaches — network dependencies. Yet you may still keep buisness confug in a single coherent place.

3. Reliability and network connectivity issues, log aggregation and monitoring is handled by infrastructure.

What is not covered:

1. Auto distribution of app instances across cluster. I’ve never seen it work w/o extensive tweaking. Therefore it is best left to a script tailored to your infrastructure.

2. scaling, because

Now the interesting part — is it too hard to implement? Maybe without intricate cluster managers and layers upon layers of abstraction, each with a unique configuration dance.
Публикации, доступные бесплатно
Уровни подписки
Единоразовый платёж

Безвозмездное пожертвование без возможности возврата. Этот взнос не предоставляет доступ к закрытому контенту.

Помочь проекту
Бронза 500₽ месяц 5 100₽ год
(-15%)
При подписке на год для вас действует 15% скидка. 15% основная скидка и 0% доп. скидка за ваш уровень на проекте Glow labs

Бронзовый уровень дает доступ к переводам моих постов на https://olshansky.me


Оформить подписку
Серебро 990₽ месяц 10 098₽ год
(-15%)
При подписке на год для вас действует 15% скидка. 15% основная скидка и 0% доп. скидка за ваш уровень на проекте Glow labs

То же самое что и бронзовый + добавление на дискорд канал посвященный деятельности Glow labs.

Оформить подписку
Золото 1 750₽ месяц 17 850₽ год
(-15%)
При подписке на год для вас действует 15% скидка. 15% основная скидка и 0% доп. скидка за ваш уровень на проекте Glow labs

Все то же, что и серебряный уровень плюс поддержка через телеграмм, 8/5.

Оформить подписку
Платина 5 000₽ месяц 51 000₽ год
(-15%)
При подписке на год для вас действует 15% скидка. 15% основная скидка и 0% доп. скидка за ваш уровень на проекте Glow labs

То же что и золотой уровень, только поддержка по телефону 24/7.

Оформить подписку
Фильтры
Статистика
1 подписчик
5 000 ₽ всего собрано
Обновления проекта
Контакты

Контакты

Поделиться
Читать: 1+ мин
G
logo
Glow labs

Medium posts

Читать: 1+ мин
G
logo
Glow labs

Внутри сборщика мусора D


На ‎конференции‏ ‎DConf ‎2017 ‎хакатоне ‎я ‎вел‏ ‎группу ‎(из‏ ‎2‏ ‎человек) ‎занимающуюся ‎druntime‏ ‎ковырявшуюся ‎в‏ ‎сборщике ‎мусора ‎D. ‎Спустя‏ ‎пару‏ ‎часов ‎я‏ ‎не ‎мог‏ ‎стряхнуть ‎чувство ‎- ‎черт ‎это‏ ‎все‏ ‎неплохо ‎бы‏ ‎переписать. ‎Так‏ ‎что ‎я ‎решил ‎начать ‎задачу‏ ‎построения‏ ‎лучшего‏ ‎сборщика ‎мусора‏ ‎для ‎D.‏ ‎Первая ‎итерация‏ ‎доожна‏ ‎быть ‎более‏ ‎быстрым ‎классическим ‎mark-sweep ‎сборщиком. ‎

Чтобы‏ ‎объяснить ‎мою‏ ‎мотивацию‏ ‎я ‎покажу ‎внутренности‏ ‎текущего ‎сборщика‏ ‎мусора, ‎перечислю ‎все ‎проблемы‏ ‎его‏ ‎дизайна. ‎Так‏ ‎или ‎иначе,‏ ‎мы ‎должны ‎анализировать ‎то, ‎что‏ ‎мы‏ ‎имеем, ‎чтобы‏ ‎понять ‎куда‏ ‎идти ‎дальше. ‎

Пулы, ‎пулы ‎повсюду

Если‏ ‎бы‏ ‎мы‏ ‎проигнорировали ‎некоторую‏ ‎глобальную ‎машинерию‏ ‎то ‎сборщик‏ ‎мусора‏ ‎это ‎просто‏ ‎массив ‎пулов. ‎Каждый ‎пул ‎это‏ ‎кусок ‎mmap-нутой‏ ‎памяти‏ ‎+ ‎пачка ‎malloc-нутых‏ ‎метаданных ‎таких‏ ‎как ‎таблицы ‎для ‎mark‏ ‎битов,‏ ‎free ‎битов‏ ‎и ‎так‏ ‎далее. ‎Все ‎аллокации ‎происходят ‎внутри‏ ‎пула,‏ ‎если ‎ни‏ ‎один ‎пул‏ ‎не ‎может ‎аллоцировать ‎память, ‎то‏ ‎создается‏ ‎новый‏ ‎пул. ‎Размер‏ ‎пула ‎определяется‏ ‎арифметической ‎прогрессией‏ ‎по‏ ‎числу ‎пулов‏ ‎или ‎150% ‎размера ‎аллокации, ‎в‏ ‎зависимости ‎от‏ ‎того,‏ ‎что ‎больше.

Любая ‎маленькая‏ ‎аллокация ‎сперва‏ ‎округляется ‎до ‎одной ‎из‏ ‎степеней‏ ‎2 ‎(класс‏ ‎размера) ‎-‏ ‎16, ‎32, ‎64, ‎128,256, ‎512,‏ ‎1024,‏ ‎2048.Затем ‎проверяется‏ ‎глобальный ‎freelist‏ ‎для ‎этих ‎классов ‎размеров, ‎если‏ ‎не‏ ‎удается‏ ‎найти ‎мы‏ ‎ищем ‎маленький‏ ‎пул. ‎Этот‏ ‎маленький‏ ‎пул ‎будет‏ ‎аллоцировать ‎новую ‎страницу ‎связывать ‎ее‏ ‎с ‎free‏ ‎list‏ ‎объектов ‎это ‎класса‏ ‎размеров. ‎И‏ ‎тут ‎видна ‎первая ‎ошибка‏ ‎дизайна‏ ‎- ‎класс‏ ‎размера ‎назначается‏ ‎каждой ‎странице, ‎и ‎следовательно ‎нам‏ ‎нужна‏ ‎таблица, ‎которая‏ ‎отражает ‎страницу‏ ‎пула ‎в ‎класс ‎размер ‎(называемой‏ ‎pagetable).

.


Обновления проекта

Статистика

1 подписчик
5 000 ₽ всего собрано

Контакты

Фильтры

Подарить подписку

Будет создан код, который позволит адресату получить бесплатный для него доступ на определённый уровень подписки.

Оплата за этого пользователя будет списываться с вашей карты вплоть до отмены подписки. Код может быть показан на экране или отправлен по почте вместе с инструкцией.

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

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

Добавить карту
0/2048