Лучшие практики Kubernetes. Создание небольших контейнеров

По мере того как вы начинаете создавать все больше и больше сервисов Kubernetes, простые по началу задачи начинают усложняться. Например, команды разработчиков не могут создавать службы или развертывания под одним и тем же именем. Если у вас тысячи подов, их простое перечисление займет кучу времени, не говоря о том, чтобы обеспечить им нормальное управление. И это только верхушка айсберга.

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



В большинстве дистрибутивов Kubernetes кластер «выходит из коробки» с пространством имен, имеющим название «default». На самом деле существует три пространства имен, с которыми Kubernetes имеет дело: default, kube-system и kube-public. В настоящее время Kube- public используется не так уж часто.

20-го февраля 2020-го года исполняется 34 года с момента запуска и ввода в эксплуатацию космической станции «Мир». Станции, которая была обитаема с 13 марта 1986 года по 16 июня 2000 года. И могла быть обитаема ещё, если бы…

Наверняка многие из вас смотрели фильм «Гравитация», который был признан одним из лучших фильмов о космосе в истории мирового кино, но мало кто знает, что на космической станции «Мир» произошли не менее драматичные события.



23 февраля 1997 года на станции «Мир» должен был погибнуть весь международный экипаж – 4 российских космонавта, один немецкий и один американский астронавт. И тогда станцию «Мир» пришлось бы затопить не планово – весной 2001 года, а вынужденно, на 4 года раньше, с мертвым экипажем на борту. Об этой экспедиции до 2006 года принято было молчать, и до сих пор о ней мало что известно, кроме самих космонавтов и руководителей полета, никто не знал подробностей случившегося. В 2006-м, космонавты 23 международной экспедиции согласились рассказать, что же на самом деле происходило на космической станции, заложниками которой они оказались и Первый канал снял отличный документальный фильм об этом — «Некуда бежать. Пожар на космической станции», который сегодня доступен на Youtube, сайт студии Роскосмоса, почему-то выдаёт ошибку. Возможно потому, что там сказали не всю правду или потому, что правда не совсем та.

Пожар потушили, но он имел страшные последствия. Несколько месяцев космонавтам пришлось жить при температуре более +40 С, дышать ядовитыми парами этиленгликоля, а затем спасать станцию от разгерметизации, вызванной столкновением с 10-тонным грузовым кораблем «Прогресс».

И совсем недавно мой друг нашёл версию произошедшего столкновения от американцев (смотреть с 1:18:00), где астронавт Майкл Фоул, непосредственный участник событий, утверждает, что столкновение было результатом эксперимента по ручной стыковке со станцией, а что самого эксперимента не должно было быть.

В agile-командах часто возникает спор, насколько детально должна быть проработана User Story, прежде чем ее следует передавать разработчикам.

Некоторым разработчикам хотелось бы видеть максимально подробное описание, прочитав которое, они могли бы сразу всё понять и быстро сделать, ни к кому не обращаясь с вопросами. Руководству также зачастую импонирует такой подход, ведь программисты стоят дорого, нужно сделать так, чтобы они не отвлекались ни на что постороннее.

Рассмотрим Agile-подход к решению этой проблемы.

Доброго времени суток, друзья!

Надеюсь, эта статья будет полезна как начинающим разработчикам, так и опытным.

В вопросах, которые показались мне сложнее прочих, приведены ссылки на дополнительную литературу.

Буду признателен за развернутые комментарии. Все замечания будут учтены при редактировании статьи.

Итак, поехали.

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

Дело в том, что ИТ-сфера одновременно бурно развивается (все еще) и в то же время полна множества устоявшихся стереотипов.

Голосовые помощники — не далёкое будущее, а реальная действительность. Alexa, Siri, Google Now, Алиса встроены в «умные» колонки, часы и телефоны. Они постепенно меняют наш способ взаимодействия с приложениями и устройствами. Через ассистента можно узнать прогноз погоды, купить билеты на самолет, заказать такси, послушать музыку и включить чайник на кухне, лежа на диване в другой комнате.



Siri или Alexa говорят с пользователями в основном по-английски, поэтому в России они не так популярны, как Алиса от Яндекса. Для разработчиков Алиса тоже удобнее: её создатели ведут блог, выкладывают удобные инструменты на GitHub и помогают встраивать ассистента в новые устройства.

Никита Дубко (@dark_mefody в Твиттере) — разработчик интерфейсов в Яндекс, организатор митапов MinskCSS и MinskJS и редактор новостей в Web-стандартах. Никита не работает в Яндекс.Диалогах и никак не связан с Яндекс.Алисой. Но ему было интересно разобраться, как Алиса работает, поэтому он попробовал применить её навыки для Web и подготовил об этом доклад на FrontendConf РИТ++. В расшифровке доклада Никиты рассмотрим, что полезного могут принести голосовые помощники и построим навык прямо в процессе чтения этого материала.

Всем привет. Меня зовут Даниил, и в этой статье я хочу поделиться с вами своей историей поступления в бакалавриат 18 университетов США. В интернете достаточно много рассказов о том, как можно учиться в магистратуре или аспирантуре совершенно бесплатно, но мало кто знает, что возможность получить полное финансирование есть и у студентов-бакалавров. Несмотря на то, что описываемые здесь события происходили давно, большая часть информации актуальна и по сей день.

Основной целью написания этой статьи было вовсе не предоставить полноценный гайд по поступлению в одни из лучших университетов мира, а поделиться собственным опытом со всеми открытиями, впечатлениями, переживаниями и прочими не слишком полезными вещами. Тем не менее, я постарался как можно подробнее описать каждый шаг, с которым придётся столкнуться любому, кто решится выбрать этот нелёгкий и рискованный путь. Получилось достаточно много и содержательно, так что заранее запаситесь чаем и присаживайтесь поудобнее — моя история длиною в год начинается.

Telegram тестирует новый вариант обхода блокировок — маскировка трафика под обычный TLS (https).

Предистория: Попытки заблокировать Telegram происходят в разных странах, первый вариант блокировки был простым — блокировка IP адресов серверов Telegram.

Telegram достаточно успешно отбивается от этой атаки, переодически меняя IP с которых он доступен, однако это вызывает долгий первичный Connecting…

Чуть позднее стали доступны Socks прокси, однако протокол не подразумевает шифрования и это позволяло достаточно просто смотреть «внутрь» socks туннеля определяя, что внутри него — Telegram, блокируя прокси.

Следующим раундом стал — выпуск MTProto Proxy — прокси сервера от Telegram, который использует свой протокол MTProto, однако и он обладал некоторыми проблемами — размер пакетов достаточно характерный и специфичный, и многие DPI начали определять Telegram уже после первого пакета — блокируя доступ.

Ответом на такое поведение стало введение новой версии протокола MTProto — с случайной длиной, теперь определить что перед нами Telegram туннель — сложнее, часть DPI начали классифицировать трафик как «другое» часть все же научились выявлять характерный паттерн и с некоторой вероятностью (не 100%) определять, что трафик относится к Telegram

Сейчас мы переходим на следующий этап (похоже финальный или пред-финальный) — стеганография.

Стеганогра́фия (от греч. στεγανός «скрытый» + γράφω «пишу»; букв. «тайнопись») — способ передачи или хранения информации с учётом сохранения в тайне самого факта такой передачи (хранения).

Другими словами — теперь Telegram будет притворяться обычным TLS (https) трафиком.

Эта статья продолжает наш недавний материал про миграцию RabbitMQ и посвящена MongoDB. Поскольку мы обслуживаем множество кластеров Kubernetes и MongoDB, пришли к естественной необходимости мигрировать данные из одной инсталляции в другую и делать это без простоя. Основные сценарии прежние: перенос MongoDB из виртуального/железного сервера в Kubernetes или же перенос MongoDB в рамках одного кластера Kubernetes (из одного пространства имён в другое).

Предисловие

Мое веб-приложение хранит данные в localStorage. Это было удобно, пока не захотелось, чтобы пользователь, заходя на сайт с разных устройств, видел одно и то же. То есть, понадобилось удаленное хранилище.

Но приложение «хостится» на GitHub Pages и не имеет серверной части. Я решил не делать сервер, а данные хранить у третьей стороны. Это дает существенные преимущества:

1. Не нужно платить за сервер, не болит голова о его стабильности и доступности.
2. Меньше кода, меньше ошибок.
3. Пользователю не нужно регистрироваться в моем приложении (это многих раздражает).
4. Приватность выше, и пользователь знает, что его данные хранятся в месте, которому он, скорее всего, доверяет больше, чем мне.

Сначала выбор пал на remoteStorage.js. Они предлагают открытый протокол обмена данными, достаточно приятное API, возможность интеграции с Google Drive и Dropbox, а также свои сервера. Но этот путь оказался тупиковым (почему — отдельная история).

В итоге решил использовать Google Drive напрямую, и Google API Client Library (далее GAPI) как библиотеку для доступа к нему.

К сожалению, документация Google разочаровывает, а библиотека GAPI выглядит недоработанной, к тому же имеет несколько версий, и не всегда понятно, о какой из них идет речь. Поэтому решение моих задач пришлось собирать по кусочкам из документации, вопросов и ответов на StackOverflow и случайных постов в интернете.

Надеюсь, данная статья сэкономит вам время, если вы решите использовать Google Drive в вашем приложении.

— Прошу внимания, коллеги. – директор постучал карандашом по столу. – Нам предстоит интересное мероприятие.

Не сразу, но тишина установилась. Коммерческий директор и главный инженер продолжали о чем-то шепотом переговариваться, иногда посмеиваясь, но, заметив строгий взгляд директора, затихли.

— Мы собрались для проведения кросс-собеседования. – продолжил директор. – И у нас тут – очень интересный экземпляр. Претендует на должность директора по информационным технологиям. Но вот резюме…

— Мда. – улыбнулась HR. – Весьма странный субъект. Подозреваю, это будет что-то… Хотя думаю, на работу мы его не возьмем.

— Почему? – спросил коммерческий.

— Сейчас сам увидишь. Он утверждает, что может какими-то там программистскими, или… — HR подняла со стола бумажку, пробежалась глазами. – Да, вот… Инженерными методами повысить эффективность бизнеса. В том числе, прибыль.

— Откуда такое чудо? – коммерческий удивленно улыбнулся.

— Из деревни какой-то… — HR снова глянула в бумажку. – Написано – Курган. Это где?

— Там, где волки срать боятся. – подхватил общее настроение главный инженер. – Бывал я там, на практике. Еле жив остался, в девяностые дело было…

— Ну что, зовем? – перебил директор.

Внезапно в дверь переговорной постучали и, тут же, не дожидаясь приглашения, вошел Сергей. Почему-то в пуховике и шапке.

— Это, парни. – сказал он извиняющимся тоном. – Простите за беспокойство, я передумал. Мне ваша компания не подходит. До свидания.

Эта статья будет интересна, кто столкнулся с разного рода проблемами после обновления Google PageSpeed и претензиям со стороны заказчиков или начальника, почему упал бал или возникло такое количество замечаний. А так же тем, кто производит оптимизацию сайтов.
В первую очередь стоит упомянуть, что вот в этой статье, на мой взгляд, всё очень грамотно и доступно расписано.

Я же от себя добавлю больше практических советов, а так же будет интересно послушать вашу точку зрения и увидеть ваши наработки.

Всем добрый день!

До конца года осталось уже почти всего ничего, но всё же несколько новинок в курсах у нас будет. Один из таких новый курсов — «Agile Delivery Manager», который создала Марина Арефьева. По традиции подготовили для вас открытые уроки и интересные материалы. Сегодня познакомимся о виденье, что же такое Delivert Manager и с чем его едят.

Поехали.

Рич Льюис (Rich Lewis) — лучший, с кем я когда-либо работал. Когда я только встретил его, он был бизнес аналитиком и скрам-мастером небольшой команды. Он справлялся со своей работой, но явно был способен на большее. Я предложил ему должность Delivery Manager в программе, которой занимался в то время.

О роли Delivery Manager мы говорим не часто. Конечно, это не часть “семьи” Agile, где доминирует терминология Scrum. Владелец Продукта; Скрам-мастер; Все остальные с ярлыком “Разработчик”. Вот, пожалуй, и все.

Тем не менее, название должности — Delivery Manager, существует. Например, в The Government Digital Service (GDS) в Великобритании и все большем количестве компаний в США.

Зачем?

UHF Reader позволяет обеспечить контроль за метками на расстоянии до 10 метров, что дает интересные перспективы различного использования. Самый очевидный – это контроль пропуска автотранспорта. Но можно придумать и более экзотичные варианты: контроль за оборудованием в гараже/сарае. Едва ли воришка додумается, что к велосипеду (чемодану с инструментом) приклеен RFID tag и он способен сообщить о своем отбытии за пределы наблюдаемого периметра.
NodeJS + RaspberryPI – гибкий и дешевый сервер обработки данных и управления периферией.

Оборудование

Я взял на тесты CF-RU5109 (CHAFON), поддерживающий соединение по RS232, RS485, Wiegand, TCP.

В этом году вы со своим приятелем Стивом Стивингтоном основали стартап по отслеживанию пользователей. Бизнес основан на утечке метаданных WhatsApp, которую вы обнаружили. Вам обоим стоило бы ещё поучиться менеджменту, но всё же фирма выросла в мощную, хотя неустойчивую компанию из 65 разномастных стажёров и студентов, фрилансеров и неоплачиваемых работников на испытательном сроке. Вы недавно переехали в щегольской новый офис в отделе литературы 19-го века Общественной библиотеки Сан-Франциско, и у вас завидная репутация в сфере интернет-маркетинга.

Но под этой глянцевой и сомнительной внешностью скрывается гниль. Вы подозреваете, что ваш хороший друг, соучредитель и со-исполнительный директор Стив Стивингтон строит козни против вас. Он всё время выбегает из библиотеки в странное время и где-то пропадает часами напролёт. Когда вы спрашиваете, куда он идет, он строит странную гримасу, которую вероятно считает злорадной ухмылкой — и говорит не беспокоиться. Вы несколько раз поручали библиотекаршам проследить за ним, но все они ужасны в полевой работе.

Избиратели делают отметки в бюллетенях на избирательном участке, расположенном в колумбарии Сан-Франциско, 5 июня 2018

Мэр Сан-Франциско Эд Ли умер в декабре 2017. Выборы его замены прошли в начале июня. Спустя почти неделю было ещё неизвестно, кто победил [оригинал статьи от 6 июня 2018 / прим. перев.]. Частично из-за того, что голоса всё ещё поступали. Голосование по почте можно просто отправить в день голосования, и спустя шесть дней, городские власти сообщали, что им осталось обработать ещё 87 000 голосов. Но это не единственное препятствие. Другая проблема кроется в математике.

Видите ли, выборы мэра Сан-Франциско – это не просто ещё одна история «побеждает набравший больше всего голосов». Эта гонка – ещё один пример культурной инновации, которую Калифорния иногда неожиданно выпускает на неподготовленную Америку, как это было со смартфонами и модными тостами. Сюрприз! Мы даже голосуем не так, как все.

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

Все рано или поздно приходят к аналитике за данными. В больших многопользовательских играх (да и синглплеере) без этого уже вообще никуда. Сколько пользователей предпочитают новый режим; где слабые места монетизации; куда смотреть геймдизайнерам, чтобы повысить вовлеченность игроков; и еще миллион вещей — подсчитывается вообще всё. И всё это влияет на решения, которые потом принимают разработчики.

А вот внедряют аналитику все по-разному: кто-то покупает сторонние решения (просто, но негибко), кто-то пишет под себя (долго и дорого), а кто-то пока просто считает несколько базовых метрик силами программистов и не заморачивается.

Поэтому я расскажу об инструменте, который будет полезен для всех. Кто только начинает выстраивать аналитику — сможет «на коленке» создать систему с нуля, а компании с уже готовыми решениями — «бустануть» свой подход.

В конце прошлого месяца 2ГИС начал отображать подъезды. Входы в организации мы показываем аж с 2013 года, а подъезды — вроде бы те же входы. Так почему только сейчас? Все внутренние продукты и процессы готовы, всего-то нужно дособрать ещё чуть-чуть да подправить отображение в UI.

Кроме стандартного ответа «Были другие приоритеты» есть и не совсем стандартный: «Не всё так просто». Эта статья про то, какие были сложности и как мы их решили.

От переводчика: я нашел на Quora вопрос: Какую программу или код можно назвать самыми сложными из когда-либо написанных? Ответ одного из учасников был настолько хорош, что вполне тянет на статью.

Пристегни ремни.

Самая сложная программа в истории была написана командой людей, имена которых нам неизвестны.

Это программа – компьютерный червь. Червь был написан, судя по всему, между 2005 и 2010 годами. Поскольку этот червь является таким сложным, я могу дать лишь общее описание того, что он делает.

Hi There!

Это перевод статьи "Norman Thuswaldner с сайта BA Times". Статья 2014-ого года, но мне показалась очень актуальной и в 2018-ом.

Начинаем!

Требования к данным — Должен ли бизнес-аналитик заботиться?

Однажды, директор ИТ-отдела сказал мне, чтобы я не думал о требованиях к данным и сосредоточился только на бизнес-требованиях. Система должна была быть разработана за 6-8 месяцев но потребовалось более двух лет, и немногие остались довольны конечным результатом. [читая этот текст, я не могу ни радоваться насколько у нас хорошо организованный проект, я работаю над созданием IT продукта, практически в каждом проекте у нас есть отдельный человек, который заботится только о данных]

Должны ли бизнес-аналитики заботиться о требованиях к данным? Что вы думаете?

К сожалению, бизнес-аналитики тратят гораздо больше времени на анализ бизнес-процессов, чем на анализ бизнес-информации. Это часто приводит к требованиям, которые рассказывают только половину истории. Когда дело доходит до построения IT систем, понимание данных не менее важно, чем понимание процессов. В современном мире немногие организации могут позволить себе перестраивать только построенную систему.

Существуют способы, который помогут собрать требования и позволят создать полную картину того, что необходимо (и только то, что необходимо), чтобы получить максимальную отдачу от проекта с первого раза. [заинтриговал]