Работа с Ingress-контроллерами обычно предполагает работу с Kubernetes в облаке, где внешние ip присваиваются автоматически. Я изучаю Kubernetes, обходясь обычным ноутбуком за NAT, на котором в виртуальных машинах запущены разные разновидности Kubernetes. Когда я разбирался с Ingress-контроллером, у меня возникло непреодолимое желание завести в него публичный ip и обратиться к нему извне. Давайте посмотрим, как это можно сделать.

Привет, друзья!

В этой серии статей я расскажу вам о Remix — новом фреймворке для создания клиент-серверных веб-приложений на JavaScript (точнее, на React) со встроенной поддержкой TypeScript.

Remix позволяет разрабатывать так называемые PESPA (Progressive Enhancement Single Page Apps — одностраничные приложения с возможностью прогрессивного улучшения). Это означает следующее:

• почти весь код приложения "живет" на сервере;
• приложение остается функциональным даже при отсутствии JS;
• JS используется только для прогрессивного улучшения UX (User Experience — пользовательский опыт).

Подробнее о PESPA и других архитектурах веб-приложений можно почитать здесь.

Очевидно, что разработчики Remix вдохновлялись Next.js и Svelte.

К слову, здесь вы найдете полное руководство по Next.js.

В первой части мы пройдемся по руководствам из официальной документации, во второй — более подробно рассмотрим возможности, предоставляемые Remix.

Это часть номер раз.

Часть номер два.

Kubernetes пожалуй является самым распространенным средством оркестрации контейнеризированных приложений. С его помощью можно автоматизировать развертывание, масштабирование и координацию работы с контейнером в условиях кластера. Благодаря этим свойствам Kubernetes (который также называют k8s) существенно сокращает время сборки, поставки и масштабирования контейнерных приложений.

Одним из замечательных свойств контейнеров k8s является их неизменяемость, то есть, если мы закрываем контейнер, то вся информация, хранящаяся в нем теряется. Это очень удобно для всевозможных тестовых и учебных сред, решений типа “песочница” и аналогичных. Суть сводится к тому, что что бы мы не делали с контейнером, после его закрытия все будет уничтожено. Мы можем запустить подозрительный файл в контейнере не опасаясь за последствия (если конечно у нас правильно настроено монтирование) и через пару минут уничтожить этот контейнер, также без последствий.

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

JSON является одним из очень простых, но в то же время эффективных языков для хранения и передачи данных. Он настолько популярен, что, пожалуй, может считаться самым совместимым форматом представления данных в мире.

Одновременно с этим, JavaScript является одним из наиболее популярных языков программирования и применяется практически везде. Также, нужно понимать, что JSON появился напрямую из JavaScript и эти два языка просто созданы друг для друга.

Но что же может пойти не так, спросите Вы? Просто попробуйте распарсить этот JSON-документ…

Может ли kubernetes сделать жизнь админов небольших и средних компаний проще или же это шайтан-машина для кровавого enterprise и оголтелых стартапов?

К Kubernetes мы присматривались два года. Изучали различные статьи, пытались его разворачивать, но после развертывания не понимали что делать дальше. Пока однажды мы не решили попробовать завернуть одну из систем в контейнер. Для оркестрации контейнера была выбрана система Docker Swarm, так как она проще, и тут возникла первая проблема – в выбранной системе была авторизация, а Docker Swarm проблема с сохранением сессии пользователя если контейнеров больше одного (мы использовали ADFS для авторизации в системе) – т.е. текущая сессия пользователя не сохранялась и при обновлении страницы выходила стартовая. Поиск различных решений сводил к одному – нужен Kubernetes с его Ingress контроллером, где есть «липкие сессии» (sticky session). При выборе дистрибутива было принято решение использовать «ванильный» k8s.

В очередной раз установив Kubernetes начался поиск решения как доставить туда наш контейнер. Контейнеры собирались на отдельной виртуальной машине и загружались в локальный Docker Container Registry, а чтобы развернуть этот контейнер в Kubernetes использовался Gitlab Runner на мастере. Не самое лучшее решение, но компетенций на другое не хватало. И вот когда Deployment был развернут возник вопрос. Как вывести контейнер наружу. Так как мы использовали Bare Metal конфигурацию, то при первом запросе в Google вылез Metal LB. Если бы мы знали тогда, что можно использовать Ingress Nginx с параметром Host Network: True, то это сэкономило бы нам месяц экспериментов с Metal LB и мы знали, что от него можно сразу отказаться. Для Metal LB использовалась L2 конфигурация, где создавался виртуальный пул адресов, который виден только внутри кластера. А как вывести это наружу? Конечно установить Nginx на мастер и прописывать виртуальные адреса в /etc/hosts, чтобы Nginx их видел. К счастью в голове тогда была мысль, что это как-то неправильно.

Резервное копирование является одной из основных задач администрирования баз данных. Отсутствие бэкапа может привести к катастрофическим последствиям при эксплуатации базы данных. Однако недостаточно только настроить регулярное создание резервных копий, необходимо также регулярно проверять созданные копии на способность к восстановлению БД. В этой статье мы поговорим от том, как правильно настраивать резервное копирование в БД PostgreSQL.

Vuetify - один из самых популярных Material Design фреймворков для Vue, которому недавно исполнилось 6 лет. И 6 января 2023 года его основатель заявил, что проект Vuetify перестал окупаться и он ищет работу. Отсюда - некролог в названии статьи.

Статья состоит из шести небольших частей, в которых мы пробежимся от первой версии до третьей, посередине разобрав, как фреймворк обновлялся до Vue 3, будем вместе смотреть за поведением основателя движка, а также тем, как можно справиться с переходом на Vue 3, пожалуй, хуже, чем кто-либо еще, включая команду Nuxt.

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

В обычной жизни я не только тестирую оборудование умного дома, но и очень много путешествую. Любимое хобби в поездках – трекинг, особенно в холмистой местности. Ходил я и по лестницам Непала, и по левадам Мадейры, и по козьим тропам Азорских островов. К чему это я? Многим облака кажутся милыми, белыми и пушистыми. Но когда ты поднимаешься по тропе, и тебя после определенной высоты накрывает облако, мало не покажется. Сыро, мокро, противно, а потом еще и скользко. Приходится разворачиваться и спускаться обратно, по скользкой каменистой тропе подниматься нельзя.

В индустрии информационных технологий в 2006 году появились свои облака, которые позволяют не тратиться на собственную инфраструктуру, а буквально в один клик использовать доступные сервисы, расположенные у облачного провайдера. Все очень просто: покупаешь «железку», ставишь приложение на смартфон, указываешь нужные сценарии – и все работает. Но нет ли здесь подвоха? Не станут ли облака препятствием, из-за которого придется разворачиваться и все менять? В этом мне как раз хочется разобраться вместе с читателями.

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

Всем привет, меня зовут Сергей, я системный архитектор в компании BIMeister, и, как вы уже догадались, сегодня мы поговорим про маппинг объектов в .net

Мы сравним несколько популярных подходов и библиотек для маппинга, дадим общее представление и посмотрим на различия, которые стоит учитывать при выборе инструментов. Статья ориентирована на младших разработчиков, которые впервые сталкиваются с темой маппинга объектов и на всех неравнодушных. В данной статье мы не будем касаться широкой темы разнообразных ОRМ-ов (Object­Relational Mapping), а также темы сериализации/десериализации данных, которую тоже часто называют маппингом, а рассмотрим сопоставление объектов между различными слоями нашего приложения, например DТО (Data Transfer Object) и объектом из базы данных, с которым оперирует Entity Framework

В данной статье я расскажу про жизненный цикл одной важной задачи - “Настроить сбор/парсер логов в Kubernetes”. Или “Почему мы решили написать свой оператор для сбора логов в Kubernetes”.

Приветствуем вас на в заключительной части Deep Dive Into Deep Link! Вот уже пятая статья цикла, а мы до сих пор не со всем разобрались. Сегодня мы ответим на вопросы:

- Почему способности path паттерны такие ограниченные?

- Как происходит диспетчеризация deep link, как его делают библиотеки навигации и мы?

- Как можно сломать обратную совместимость?

Всем привет. Меня зовут Добрый Кот Telegram.

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

Вошли и вышли, приключение на 20 минут)

От коллектива FR-Solutions и при поддержке @irbgeo Telegram : Продолжаем серию статей о K8S.

Вышел .NET 7, а это значит, что можно вдоволь насладиться различными нововведениями и фишками. Расскажем про самые интересные улучшения: C# 11, контейнеры, производительность, GC и прочее.

В этой статье сравним MongoDB и Cassandra — две самые популярные NoSQL базы данных.

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

Для начала нужно определиться с типом СУБД: SQL или NoSQL. Если вы выберите NoSQL, то дальше появляется вопрос: MongoDB или Cassandra. Да, на рынке существует множество NoSQL-баз данных, но среди них лидируют MongoDB и Apache Cassandra. Оба продукта похожи, но все-таки разные. Давайте сравним эти две СУБД, чтобы сделать правильный выбор.

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

Приходят пользователи и просят: «Вот мы внесли данные в базу, а скажите нам, чего не хватает? Какие данные мы ещё не внесли в базу и их не хватает для полного счастья?»
Первая (и скажем честно, весьма глупая) реакция: «Как же я вам найду то, чего нет в базе данных?».

Но отбросим эмоции и применим логику. Ведь, как правило, требуются данные, формирование которых подчиняется некоему правилу — номера квитанций, справок и так далее… И я исхожу из того, что все эти номера и идентификаторы могут быть преобразованы в натуральную последовательность.
То есть задача будет сформулирована следующим образом: в базе данных хранится последовательность натуральных чисел, в которой есть пропуски, и необходимо вывести пропущенные числа для пользователя.
В такой формулировке задача уже выглядит достаточно простой. Более того — возникает желание реализовать эту задачу одним единственным sql-запросом.