DevOps
Всё началось в моего вопроса в Toster. И вот уже полгода как я использую медиа сервер Plex. Для тех, кто о нём не слышал, поясню: это ПО, которое анализирует и структурирует вашу медиатеку, и предоставляет к ней доступ через web и не только, эдакий персональный Netflix без регистрации и SMS. Я использую Plex для просмотра фильмов и сериалов через браузер на ноутбуке или Chromebook.
Раньше мне приходилось настраивать NFS или Samba share, колдовать с automount(8), мириться с отваливанием share после suspend-resume, или просто копировать файлы по sftp/scp, но теперь я использую Тайд Plex. К сожалению, с ним тоже не всё просто.
Задайте себе вопрос — как правильно хранить пароль от базы данных, которая используется вашим сервисом? В отдельном репозитории с секретами? В репозитории приложения? В системе деплоя (Jenkins, Teamcity, etc)? В системе управления конфигурациями? Только на личном компьютере? Только на серверах, на которых работает ваш сервис? В некоем хранилище секретов?
Зачем об этом думать? Чтобы минимизировать риски безопасности вашей инфраструктуры.
Начнём исследование вопроса с определения требований к хранению секретов.
Всем известно, что с помощью ssh можно делать перенаправление портов (создавать туннели). Еще из мануала по ssh вы могли узнать, что OpenSSH умеет динамически открывать порты для удаленного перенаправления и выполнять строго определенные команды. Также всем известно, что для Ansible (не считая Tower) нет такого понятия как сервер и клиент (в смысле ansible-server/ansible-agent) — есть сценарий (playbook) который можно выполнить как локально, так и удаленно через ssh-соединение. Еще есть Ansible-pull, это скрипт который проверяет git-репозиторий с вашими плейбуками и при наличии изменений запускает плейбук для применения обновлений. Там где нельзя пушить в большинстве случаев можно использовать pull, но бывают исключения.
После неудачной попытки первой версии статьи, когда материал заминусовали из-за чудовищного дизайна приведенного в статье примера программы (статью пришлось удалить), я учел все минусы и привожу более поздний вариант тестового приложения.
Возможно, для вас будет новостью, но разрабатывать мобильные приложения с функционалом, который доступен Java разработчикам, под Android с помощью фреймворка Kivy не просто просто, а очень просто! Именно этого правила я придерживаюсь, создавая свои проекты с Python + Kivy — разработка должна быть максимально простой и быстрой. Как щелчок пальцами.
На новичков подаваемая информация не расчитана, я не буду на пальцах объяснять, что, откуда и куда. Думаю, те, кто читает данную статью, обладают достаточными для понимания материала, знаниями. К тому же, Kivy, как я уже только что написал, очень простой фреймворк и вся документация с примерами использования находится в исходниках!
Совсем недавно на Хабре было 2 статьи о том, как автоматизировать процесс скачивания новых серий с торрентов. Авторы обеих статей поделились своими приложениями. Вот уже год мы тоже разрабатываем подобное приложение и мне кажется, пришло время рассказать хабрасообществу о нашем маленьком, но прекрасном проекте Monitorrent, который, возможно, сделает вашу жизнь настолько проще и удобнее, насколько сделал нашу.
Веб приложение написано на Python 2 (с поддержкой Python 3). Оно позволяет добавлять новые торренты для мониторинга, автоматически скачивать новые серии и добавлять их в торрент клиент.
Мы им пользуемся на постоянной основе с конца прошлого года, а 1 мая 2016 мы выпустили первую релизную версию, которая без каких-либо сбоев крутится до сих пор на cubietruck в docker контейнере.
За подробностями того как оно работает внутри прошу под
В качестве вступления стоит сказать что я пользуюсь macOS и потому некоторые части:
будут специфичны для этой ОС. Однако, если Вас заинтересует проект, думаю, поменять пару путей и слегка поправить несколько функций, чтобы заставить этот код работать с Вашей системой уведомлений, yaml'ом и, допустим, кроном, не составит труда.
Итак, к делу.
Проверять трекеры на обновления любимых телевизионных шоу, вспоминать в момент когда вышел новый эпизод, смотрел ли ты предыдущий, — надоедает. К тому же, как известно, все что нужно делать больше двух раз, стоит автоматизировать. Проект был начат на скорую руку и, вероятно, будет совершенствоваться.
class MyCounter(object):
def __init__(self):
self.__counter = 0
def incCounter(self):
self.__counter += 1
def getCounter(self):
return self.__counter
class MyCounter(SyncObj):
def __init__(self):
super(MyCounter, self).__init__('serverA:4321', ['serverB:4321', 'serverC:4321'])
self.__counter = 0
@replicated
def incCounter(self):
self.__counter += 1
def getCounter(self):
return self.__counter
D3.js (или просто D3) — это JavaScript-библиотека для обработки и визуализации данных с невероятно огромными возможностями. Я, когда впервые узнал про нее, наверное, потратил не менее двух часов, просто просматривая примеры визуализации данных, созданных на D3. И конечно, когда мне самому понадобилось строить графики для небольшого внутреннего сайта на нашем предприятии, первым делом вспомнил про D3 и с мыслью, что “сейчас я всех удивлю крутейшей визуализацией”, взялся изучать исходники примеров…
В какой-то момент разработки проекта встал вопрос поиска по большому количеству текстов. Причем, тексты имеют различную длину: от твиттов до больших статей. Сначала, основным поисковым движком был выбран встроенный в Postgres _tsvector. Для поиска по простым правилам его было вполне достаточно. Массив текстов рос с большой скоростью, а правила поиска усложнялись, поэтому встроенный движок уже не покрывал требований.
Да, существует sphinx, у него есть отличная интеграция с Postgres, но была цель найти решение для использования elasticsearch с Postgres. Почему? elasticsearch показывал хорошие результаты в некоторых case-ах проекта. Да и уже был сервер с ним для хранения логов logstash-а. Также было желание найти такой инструмент, который полностью возьмет на себя синхронизацию данных.
В результате всего на просторах сети был найден проект ZomboDb, который как раз подходил под требования.
В ходе работы с микросервисами мы неоднократно сталкивались с проблемами сервис дискавери при автоскелинге, схлопывании лишних нод.
Были перепробованы почти все решения существовавшие или существующие на данный момент, но как водится — ничего не ложилось идеально на наши динамичные окружения (десятки остановок/запусков однотипных контейнеров в час). Наиболее близкое решение было NGINX+Consul+Consul templates, но оно было некрасивым, требовало перезапуска, не давало возможности использовать внешние хелсчеки иначе как через Consul.
В общем, как всегда бывает — было принято решение написать свое решение. В процессе обсуждения всплыли десятки вещей, которые хорошо было бы реализовать, из них были выбраны самые критичные для нас и интересные для общественности.