С сервисом докера общение идет через сокет, т.е. ничего не мешает с ним общаться по сети, например, через ssh. Простейший вариант — установить переменную окружения DOCKER_HOST как ssh://${USER}@${HOST}. После этого все докер команды будут выполняться на удаленной машине. Можно немного заморочиться и использовать контексты, переключаясь между ними.

Это может быть удобно во всяких скриптах деплоя, например в gitlab-ci. Вместо заворачивания в скрипт или добавления перед каждой командой ssh user@host... просто писать команды и все. Другое преимущество — переменные окружения будут браться локально, а еще локально будут копироваться артефакты через docker cp container:/container/path local/path.

А вот и доклад посвежее про Erlang, полуторагодичной давности. В нем кратко объясняется идея акторов и рассказывается о системе учета пациентов, построенной на этой модели. В какой-то момент там внезапно появляются фильтр Блума, рандеву-хеширование, алгоритмы консенсуса и выбора лидера.

Стоит отметить, что система не является основным источником информации (а только для всякой бигдаты), поэтому вопросы того, как делать все транзакционно, тут не поднимаются (впрочем, пациенты довольно изолированы друг от друга, так что это ок, наверно). А так получается практически event sourcing.

Занятный, хоть и немного старый доклад про проблемы построения отказоустойчивых распределенных систем от автора языка Erlang. Сначала небольшое вступление и полунаглядные примеры, потом на 30 минуте начинается мякоть. Сформулированы 6 правил для потенциального решения проблем:

1. Изоляция
2. Конкурентность
3. Обнаружение ошибок
4. Понимание, почему они возникли
5. Обновление кода
6. Стабильное хранилище

Один из ключевых подходов — “let it crash”. Убийца — дворецкий, Erlang и модель акторов решают все проблемы:)

Я бы посмотрел на этот доклад с двух сторон. Во-первых, со стороны текущих проектов: а как это решается не Erlang’ом? Кубер, телеметрия, helm, postgres, какая-нибудь очередь для доменных событий — вроде уже типовой стек и он почти работает, да? А во-вторых, докладу скоро 10 лет — хорошо ли он состарился?

Недавно наткнулся на случай, когда они пригодились. Рассмотрим пример:

data class OptionalResult(val data: Payload?, val someFlag: Boolean)

fun OptionalResult?.getData(): Payload {
	this ?: throw NoResultException()
	return this.data ?: throw NoPayloadException()
}

fun someFun(){
	val payload: Payload = getResult().getData()
	doStuffWithPayload(payload)
	if (payload.someFlag){ //oopsie
		// do more stuff 
	}
	...
}

По сути имеем дважды опциональный результат, и в ФП-парадигме это красиво легло бы в мона.. Option, но у нас Kotlin с исключениями. Однако строка с oopsie вызовет ошибку компиляции, т.к. компилятор не понимает, что payload уже был проверен на null. Причем если тело функции подставить вместо вызова, то все будет ок (ссылочная прозрачность плачет в уголочке). Чтобы решить проблему, можно использовать контракты и явно сказать компилятору, что если функция что-то вернула, то ее аргумент — не null:

fun OptionalResult?.getData(): Payload {
	contract {
		returns() implies (this@getData != null)
	}
	this ?: throw NoResultException()
	return this.data ?: throw NoPayloadException()
}

В общем, фича интересная, но, кажется, компилятору стоит быть поумнее.

Лучше такой пост, чем никакой, наверно :/

1. Создаем исполняемый скрипт. Его нужно создать через sudo, чтобы нельзя было редактировать. Иначе это будет дырищей, через которую можно будет запускать что угодно.

sudo nano /usr/sbin/some_command
# добавляем shebang и саму команду
# ...
sudo chmod +x /usr/sbin/some_command

2. Добавляем настройку через sudo visudo, обязательно в конец файла.

some_user ALL=(ALL) NOPASSWD: /usr/sbin/some_command

some_user — имя пользователя.

3. Теперь можно запускать команду через sudo some_command, и пароль не будет запрашиваться. Можно повесить на хоткей какой-нибудь.

Мне пригодилось для того, чтобы рестартовать демон частоты процессора. Ноут почему-то периодически решает, что 400 MHz хватит всем, почему — быстро не докопался, поэтому решил костылем.

Оказывается, уже давненько в Elasticsearch можно собрать шаблон индекса по кусочкам, причем их можно переиспользовать — например, какие-нибудь преобразования текста типа стемминга вынести в общий кусочек. Долой копипасту!

В дополнение к предыдущему посту — занятная проблемка. По умолчанию go build генерирует исполняемый файл прямо в корень проекта (sic!). Исполняемый файл в репозитории мы не хотим хранить, и чтобы его исключить, обычно делают Makefile (еще один прекрасный язык, кстати) или добавляют в .gitignore название проекта. Но есть способ поинтереснее:

*
!/**/
!*.*

Тут сначала игнорируются все файлы, потом с помощью отрицания (!) разрешаются все файлы внутри папок и все файлы, имеющие расширение. Правда, отвалится Dockerfile, но у него хотя бы имя фиксированное.

По работе надо было написать микросервис для перекладывания JSON’ов, решил дать еще один шанс языку Go и написать на нем, с разбором впечатлений, как для Elm или Rust. Микросервис-то я написал, а вот пост писать раздумал, решил ограничиться примером, который, как мне кажется, довольно показательный.

Вот у нас есть метод из стандартной библиотеки, log.Fatal. Что он делает?

Ок, а что делают log.Info и log.Error?

Приезжает дальнобойщик домой, думает, в какую бы игру залипнуть для расслабона — Euro Truck Simulator, каеф!

Если не хватает подобного для решения проблем в Linux — есть игруля. Задания не очень сложные, местами жизненные. Если непонятно, что делать, то есть подсказки и можно даже какие-то команды новые узнать.

Бонус для ИБшников и прочих хакеров — вам дают рутовый доступ к временному контейнеру в AWS, RCE as a Service, налетай!

Подробный сборник всех опций популярных JVM с поиском и значениями по умолчанию.