Forwarded from HABR FEED + OPENNET
Вебинар «Нужен ли вам Kubernetes» 15 октября в 19:00
https://habr.com/post/426103/
Tags: Системное администрирование, Серверное администрирование, DevOps, Блог компании Southbridge, kubernetes, вебинар
Author aSkobin on #habrahabr
https://habr.com/post/426103/
Tags: Системное администрирование, Серверное администрирование, DevOps, Блог компании Southbridge, kubernetes, вебинар
Author aSkobin on #habrahabr
Habr
Вебинар «Нужен ли вам Kubernetes» 15 октября в 19:00
Кубернетес — распиаренная технология. Те, кто не умеет работать с кубом, пытаются внедрить его туда, где он не нужен. Страдают все: заказчики, админы, репутация Кубернетес. Southbridge организует...
Многие пользователи Kubernetes знают про etcd, что есть такая штука и она там где-то внутри используется. Вот тут вы можете потыкать и посмотреть как работает кластер etcd и что бывает, если выводить-вводить ноды, как он разваливается и проводит выборы.
http://play.etcd.io/play
#etcd
http://play.etcd.io/play
#etcd
Forwarded from Sys-Admin InfoSec (sys_admin_poster_bot)
13 сентября состоялась закрытая конференция Microsoft «DevOps Summit», где эксперты делились опытом и рассказывали, как эффективно организовывать процессы создания продуктов внутри любой компании. Всем понятно, что развёртывание, разработка, тестировые среды потихоньку перебираются в облако и, если ИТ для вас не только работа, но и реальный интерес, посмотрите запись саммита, который доступен по этой ссылке:
https://aka.ms/ds_tg3
https://aka.ms/ds_tg3
Красношапые расскажут про ansible https://www.redhat.com/en/events/ansible-automates-moscow-2018 #ansible
Анализ-сравнение производительности ectd с consul и Zookeeper
https://coreos.com/blog/performance-of-etcd.html
Хотелось бы отдельно выделить утилиту, которая использовалась для анализа, которая расположена тут https://github.com/etcd-io/dbtester , очень крутая тулза и подробное описание методики тестирования, а так же есть постоянно обновляемые отчеты https://github.com/etcd-io/dbtester/tree/master/test-results
Советую покопаться в этой репе - на основе этой методики и некоторых утилит, вы вполне можете собрать свой "бенчмаркинг" для собственных систем.
#ectd #consul #zookeeper #benchmark #dbtester
https://coreos.com/blog/performance-of-etcd.html
Хотелось бы отдельно выделить утилиту, которая использовалась для анализа, которая расположена тут https://github.com/etcd-io/dbtester , очень крутая тулза и подробное описание методики тестирования, а так же есть постоянно обновляемые отчеты https://github.com/etcd-io/dbtester/tree/master/test-results
Советую покопаться в этой репе - на основе этой методики и некоторых утилит, вы вполне можете собрать свой "бенчмаркинг" для собственных систем.
#ectd #consul #zookeeper #benchmark #dbtester
Redhat
Open Hybrid Cloud
No single cloud fits all. Explore how we build a more flexible future with hybrid cloud.
Forwarded from запуск завтра
Супер крутой интерактивный рассказ про то, как устроен TLS (который ещё зовут SSL'ем). Разобран буквально каждый байт, переданный между клиентом и сервером.
Forwarded from 4gophers
Forwarded from DocOps
Митап 14 октября в Москве: техническая коммуникация / управление знаниями
По традиции, еду из Новосибирска, чтобы организовать митап Write the Docs Moscow.
В программе три-четыре коротких доклада, форсайт-сессия и афтепати. Темы докладов скоро будут в @docops.
Что делать участникам:
0. Если хотите выступить, подайте заявку на доклад. За две недели можно подготовить отличный доклад, организаторы вам помогут.
1. Зарегистрируйтесь на митап. Вход свободный, но места ограничены.
2. Позовите на митап коллег!
3. Готовьтесь к афтепати. После митапа отправимся в Гастропаб 31 на Шаболовке, это в том же здании.
Ссылка на трансляцию будет в @docops перед началом митапа. Записи докладов будут позже на YouTube.
Обсуждение — в чате @docsascode.
#writethedocs #writethedocs_moscow
По традиции, еду из Новосибирска, чтобы организовать митап Write the Docs Moscow.
В программе три-четыре коротких доклада, форсайт-сессия и афтепати. Темы докладов скоро будут в @docops.
Что делать участникам:
0. Если хотите выступить, подайте заявку на доклад. За две недели можно подготовить отличный доклад, организаторы вам помогут.
1. Зарегистрируйтесь на митап. Вход свободный, но места ограничены.
2. Позовите на митап коллег!
3. Готовьтесь к афтепати. После митапа отправимся в Гастропаб 31 на Шаболовке, это в том же здании.
Ссылка на трансляцию будет в @docops перед началом митапа. Записи докладов будут позже на YouTube.
Обсуждение — в чате @docsascode.
#writethedocs #writethedocs_moscow
В догонку интересные размышления про редакторы-ide. Доля истины (на мой взгляд существенная) в этом есть
Forwarded from DocOps
Как фичи текстового редактора вредят автору.
Павел Молянов гневается на авторов, которые ставят лишние пустые строки между абзацами. Поделюсь мыслями о том, почему авторы так делают и как им помочь.
Обычно абзацы в тексте и так разделяются: увеличенным расстоянием между строками, реже красной строкой или как-то ещё. Стиль абзаца задаётся один раз на весь документ: в CSS для веба или в настройках визуального (WYSIWYG) редактора. Авторы не должны вручную менять стиль конкретных элементов текста. Зачем же они это делают? А потому что могут.
Визуальные текстовые редакторы позволяют «играть шрифтами», менять отображение каждого элемента и вёрстку страницы целиком. В них можно вручную поставить пустой абзац, повыделять всё полужирным и цветами и ещё анимацию добавить. Раз фича есть, люди ей пользуются, вольно или невольно.
Легковесные языки разметки, напротив, дают автору очень мало свободы, зато исправляют ошибки за автора. Так, в Markdown, rST и AsciiDoc любое количество пустых строк — это просто начало нового абзаца, а все абзацы имеют один стиль. Фичи «испортить дизайн» просто нет.
Языки разметки — как кубики Лего. Они жесткие, соединяются только как задумано, зато из них можно город построить. А визуальные редакторы — как песок. Как будто бы у вас полная свобода, но на деле вы будете бегать и исправлять осыпающиеся стенки.
Именно поэтому README на Гитхабе обычно выглядят чисто и красиво, а форумные посты — убого и вырвиглазно.
Вывод: чтобы не исправлять вручную пустые строки, лишние пробелы и кривые стили, используйте языки разметки. И да пребудет с вами сила.
#docops_markups #docops_bestpractice
Павел Молянов гневается на авторов, которые ставят лишние пустые строки между абзацами. Поделюсь мыслями о том, почему авторы так делают и как им помочь.
Обычно абзацы в тексте и так разделяются: увеличенным расстоянием между строками, реже красной строкой или как-то ещё. Стиль абзаца задаётся один раз на весь документ: в CSS для веба или в настройках визуального (WYSIWYG) редактора. Авторы не должны вручную менять стиль конкретных элементов текста. Зачем же они это делают? А потому что могут.
Визуальные текстовые редакторы позволяют «играть шрифтами», менять отображение каждого элемента и вёрстку страницы целиком. В них можно вручную поставить пустой абзац, повыделять всё полужирным и цветами и ещё анимацию добавить. Раз фича есть, люди ей пользуются, вольно или невольно.
Легковесные языки разметки, напротив, дают автору очень мало свободы, зато исправляют ошибки за автора. Так, в Markdown, rST и AsciiDoc любое количество пустых строк — это просто начало нового абзаца, а все абзацы имеют один стиль. Фичи «испортить дизайн» просто нет.
Языки разметки — как кубики Лего. Они жесткие, соединяются только как задумано, зато из них можно город построить. А визуальные редакторы — как песок. Как будто бы у вас полная свобода, но на деле вы будете бегать и исправлять осыпающиеся стенки.
Именно поэтому README на Гитхабе обычно выглядят чисто и красиво, а форумные посты — убого и вырвиглазно.
Вывод: чтобы не исправлять вручную пустые строки, лишние пробелы и кривые стили, используйте языки разметки. И да пребудет с вами сила.
#docops_markups #docops_bestpractice
Forwarded from CatOps
Смотрите какую прелесть нашел - теперь можно ООМ алертить https://github.com/cirocosta/dmesg_exporter
#dmesg #prometheus #exporter
#dmesg #prometheus #exporter
GitHub
GitHub - cirocosta/dmesg_exporter: A "dmesg" prometheus exporter - metrics from the kernel messages ring buffer
A "dmesg" prometheus exporter - metrics from the kernel messages ring buffer - cirocosta/dmesg_exporter
Forwarded from Go Дайджест
Хоршая статья с примерами использования знаменитого пакета errors, от Дейва Чейни. 🧔🧐👇
https://medium.com/@boltmick1/golang-handling-errors-gracefully-8e27f1db729f
https://medium.com/@boltmick1/golang-handling-errors-gracefully-8e27f1db729f
Medium
Golang — handling errors gracefully
Although go has a simple error model, at first sight, things are not as easy as they should. In this article, I want to provide a good…
Статья про мониторинг redis - инструменты, какие метрики что значат, на что ставить алерты и трешхолды на них.
https://blog.serverdensity.com/monitor-redis/
#redis #monitoring
https://blog.serverdensity.com/monitor-redis/
#redis #monitoring
Ну что, второй обучающий HUG митап на подходе https://www.meetup.com/HighLoad-User-Group/events/255553862
То чего давно не хватало вашим стейтлесс приложениям ;) https://habr.com/post/426133/
Habr
Знакомимся с альфа-версией снапшотов томов в Kubernetes
Прим. перев.: оригинальная статья была недавно опубликована в блоге Kubernetes и написана сотрудниками компаний Google и Huawei (Jing Xu, Xing Yang, Saad Ali)...