В последнее время я получаю достаточно много вопросов по поводу организации стораджа в OpenNebula. В виду своей специфики она имеет аж три разных типа хранилища: images, system и files. Давайте разберёмся зачем нужен каждый из них и как их использовать чтобы планировать размещение данных наиболее эфективно.
Этот пост — частичная расшифровка моего доклада про OpenNebula на HighLoad++ 2019 с упором на дисковую составляющую.
Крупнейшая профессиональная конференция для разработчиков высоконагруженных систем Saint HighLoad++ 2026
Подробнее: https://clck.ru/3QZHTb
При поддержке AvitoTech мы впервые публикуем все видео с HighLoad++ 2019 в открытый доступ. Учитесь, вдохновляйтесь и перенимайте лучшие практики у спикеров, не выходя из дома.
В продолжение предыдущей статьи про инструменты деплоя в Kubernetes, хочу рассказать вам про то как можно использовать Jsonnet для упрощения описания джоб в вашем .gitlab-ci.yml
Есть монорепа, в которой:
10 Dockerfiles
30 описанных деплоев
3 окружения: devel, staging и production
Настроить пайплайн:
Сборка Docker-образов должна производиться по добавлении git-тэга с версией.
Каждая операция деплоя должна выполняться при пуше в ветку окружения и только по изменении файлов в конкретной директории
Привет! За последнее время вышло много классных инструментов автоматизации как для сборки Docker-образов так и для деплоя в Kubernetes. В связи с этим решил поиграться с гитлабом, как следует изучить его возможности и, конечно же, настроить пайплайн.
Вдохновлением для этой работы стал сайт kubernetes.io, который генерируется из исходных кодов автоматически, а на каждый присланный пул реквест робот автоматически генерирует preview-версию сайта с вашими изменениеми и предоставляет ссылку для просмотра.
Я постарался выстроить подобный процесс с нуля, но целиком построенный на Gitlab CI и свободных инструментах, которые я привык использовать для деплоя приложений в Kubernetes. Сегодня я, наконец, расскажу вам о них подробнее.
Вот наконец-то купил себе новый ноут. Долго выбирал из всевозможных вариантов, остановился на Lenovo ideapad 720S-13ARR с процессором AMD Ryzen 7 2700U, NVMe, Type-C и прочими прелястями жизни.
На скриншоте - powerlevel10k, улучшенная и ускоренная версия powerlevel9k, лучшего powerline-шелла для zfs, ну и несколько интересных плагинов которые позволяют разукрасить консоль подобно fish.
Справа выводятся модули:
В качестве рутовой файловой системы - btrfs. Каждый вызов pacman содаёт снапшот и в любой момент можно в него загрузиться прямо из меню grub.
Ноут использую как дома, так и на работе. На работе подключаю его через Type-C док-станцию с двумя мониторами через displaylink, очень удобно. Очень порадовало наличие аппаратного шифрования NVMe-диска и возможность зарядки от пауэрбанка, а процессор AMD достаточно производителен и не подвержен уязвимостям Meltdown и Spectre.
Вот ядро
Которое построил Линус.
А это системный процесс,
Который работает без умолку,
В ядре,
Которое построил Линус.
А это суровый cgroup,
Который изолирует системный процесс,
Который работает без умолку,
В ядре,
Которое построил Линус.
Вот контейнер,
Который генерит суровый cgroup,
Который изолирует системный процесс,
Который работает без умолку,
В ядре,
Которое построил Линус.
Вот под,
Что часто пинает контейнер,
Который генерит суровый cgroup,
Который изолирует системный процесс,
Который работает без умолку,
В ядре,
Которое построил Линус.
Хочу рассказать как безопасно хранить SSH-ключи на локальной машине, не боясь того, что какое-то приложение может украсть или расшифровать их.
Статья будет полезна тем, кто так и не нашел элегантного решения после паранои в 2018 и продолжает хранить ключи в $HOME/.ssh.
Для решения данной проблемы предлагаю использовать KeePassXC, который является одним из лучших менеджеров паролей, он использует сильные алгоритмы шифрования, а также имеет встроенный SSH-агент.
Это дает возможность безопасно хранить все ключи прямо в базе паролей и автоматически добавлять их в систему при её открытии. Как только база будет закрыта, использование SSH-ключей также станет невозможным.
