От переводчика. Продолжая серию переводов про DevOps, в этот раз хочется поговорить о том, как делать НЕ надо. Мы сталкивались с этим, каждый раз, когда приходит что-то новое, например agile. Возникают культы карго, слышаться речи, что мы особенные и у нас все не так и так далее. Так давайте же попробуем избежать этого в случае DevOps.

Итак, вы хотите стать DevOps? Хорошо, но прежде чем начать, давайте взглянем на некоторые вещи, которые вы не должны делать.

В старые добрые времена, мы просто называли их «плохие идеи», но появилась дипломатия и политкорректность, ушел «мозговой штурм» и появился «idea shower», а вместе с ним и слово «анти-паттерны».

Если «паттерн» это правильный путь, то по своей сути «анти-паттерн» является неправильным — и поэтому, чтобы не дать вам пойти неверным путем, мы составили этот список (с небольшой помощью DevOps сообщества).

Этой весной, Питер Тиль (Peter Thiel), один из основателей PayPal и первый инвестор FaceBook, провел курс в Стенфорде — «Стартап». Перед началом Тиль заявил: «Если я сделаю свою работу правильно, это будет последний предмет, который вам придется изучать».

Один из студентов лекции записывал и выложил транскипт. В данном хабратопике я делаю перевод первого занятия. Если пост покажется стоящим — продолжу переводить и выкладывать.

Конспект лекций — Питер Тиль (курс: CS183) Стартап — Стэнфорд, весна 2012 г.

Занятие 1: Вызов будущего
Занятие 2: Снова как в 1999?
Занятие 3: Системы ценностей
Занятие 4: Преимущество последнего хода
Занятие 5: Механика мафии
Занятие 6: Закон Тиля
Занятие 7: Следуйте за деньгами
Занятие 8: Презентация идеи (питч)
Занятие 9: Все готово, а придут ли они?
Занятие 10: После Web 2.0
Занятие 11: Секреты
Занятие 12: Война и мир
Занятие 13: Вы — не лотерейный билет
Занятие 14: Экология как мировоззрение
Занятие 15: Назад в будущее
Занятие 16: Разбираясь в себе
Занятие 17: Глубокие мысли
Занятие 18: Основатель — жертва или бог
Занятие 19: Стагнация или сингулярность?

С тех пор как число активных пользователей Instagram стало постоянно расти, Postgres оставался нашим надежным фундаментом и неизменным хранилищем данных для большинства данных, создаваемых пользователями. И хотя меньше года назад мы писали о том, как мы храним большое количество данных на Instagram при 90 лайках в секунду, сейчас мы обрабатываем более 10000 лайков в секунду – и наша основная технология хранения данных не изменилась.

За последние два с половиной года, мы поняли несколько вещей и подобрали пару инструментов для масштабирования Postgres и мы хотим ими поделиться – то, что мы хотели бы знать при запуске Instagram. Некоторые из них специфичны для Postgres, другие представлены также и в других базах данных. Чтобы знать, как мы горизонтально масштабируем Postgres, смотрите наш пост Sharding and IDs at Instagram

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

Предположим что у нас есть postgresql в режиме потоковой репликации. master-сервер и hot-standby готовый заменить погибшего товарища. При плохом развитии событий, нам остается только создать trigger-файл и переключить наши приложения на работу с новым мастером. Однако, возможны ситуации когда вполне законные изменения были сделаны криво написанной миграцией и попали как на мастер, так и на подчиненный сервер. Например, были удалены/изменены данные в части таблиц или же таблицы были вовсе удалены. С точки зрения базы данных все нормально, а с точки зрения бизнеса — катастрофа. В таком случае провозглашение горячего hot-standby в мастера, процедура явно бесполезная…
Для предостережения такой ситуации есть, как минимум, два варианта…

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

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

Решаемая задача. Исходные данные

Итак, имеем сервер БД, с которым работают клиенты, и резервный сервер, на который надо настроить репликацию с основной базы данных.
В моём случае используется PostgreSQL 9.2.1, который установлен на обоих серверах и поддерживает потоковую репликацию. Предположим что база данных на основном сервере развернута и работает, на резервном только установлен, но не настроен PostgreSQL. Для примера возьмем IP-адрес 192.168.1.1 за адрес основного сервера, IP-адрес 192.168.1.2 — за адрес резервного.

Асинхронная потоковая репликация — полезная штука. Для нее нынче есть много различных утилит, можно выстроить большую, мощную и верную систему.

Но предположим, что у Вас небольшая задача, пара серверов и встроенная postgres-репликация. О ее настройке материалов достаточно, и о действиях в случае отказа мастера тоже можно найти.

А вот с вопросом восстановления мастера оказалась беда, поэтому делюсь с Вами собранным по кусочкам с просторов интернета руководством к действию, опробованным и протестеным мною на связках серверов Debian GNU/Linux и FreeBSD 8.2 с PostgreSQL 9.1

Есть концепции работы с базой, основанные на ORM, CodeFirst со своими преимуществами и недостатками. Предлагаемая здесь унификация базы основана в первую очередь на подходе Database First.

Схема базы данных приложений со сложной доменной моделью (к которым относятся системы ERP) обычно состоит из
нескольких сотен таблиц.
Поэтому на начальном этапе проектирования базы для избежания многократных дублирований и разбухания схемы важно
определиться с несколькими базовыми таблицами для хранения общих свойств базовых сущностей приложения
и все остальные таблицы уже проектировать как вспомогательные или дополнения основных таблиц.

Классический сценарий

Вы работаете над проектом, где транзакционные данные хранятся в базе данных. Затем вы развёртываете приложение в рабочей среде, и производительность великолепна! Запросы проходят шустро, и задержка при их вводе практически незаметна. Через несколько дней/недель/месяцев база данных становится всё больше и больше, и скорость запросов замедляется.

Есть несколько подходов, с помощью которых можно ускорить работу вашего приложения и базы данных.

Администратор базы данных (DBA) посмотрит и проследит, чтобы база данных была оптимально настроена. Он предложит добавить определённые индексы, убрать логирование на отдельную партицию, подправить параметры движка базы данных и убедиться, что база данных здорова. Можно также добавить выделенных IOPS (Input/Output Operations Per second) на EBS диске, чтобы увеличить скорость дисковых партиций. Это даст вам выиграть время и даст возможность решить главную проблему.

Рано или поздно вы поймёте, что данные в вашей базе данных являются узким местом (botleneck).
В базах данных многих приложений важность информации уменьшается со временем. Если вы сможете придумать способ избавиться от этой информации, ваши запросы будут проходить быстрее, время создания бэкапов уменьшится, и вы сэкономите кучу места. Вы можете удалить эту информацию, однако тогда она пропадёт безвозвратно. Вы можете послать множество DELETE запросов, вызвав создание тонн логов, и использовать кучу ресурсов движка базы данных. Так как же мы избавимся от старой информации эффективно, но не потеряв её навсегда?
В примерах мы будем использовать PostgreSQL 9.2 на Engine Yard. Вам также нужен git для установки plsh.

Большой темой майского номера «Хакера» стал Raspberry Pi. Мы пообщались с создателем «малинки», Эбеном Аптоном и узнали, каковы итоги первого года проекта, и что ждет маленький компьютер в следующем. Также мы описали два концепта на основе Raspberry: незаметную закладку, которая в виду размеров может незаметно собирать данные из сети (принимая команды по SMS и скидывая логи в Evernote), а также систему видеонаблюдения, интегрированную с Google Drive. Один из этих концептов мы предлагаем вашему вниманию.




Идея дропбокса проста: если миниатюрный компьютер снабдить батареей и 3G-модемом, то можно получить шпионскую коробочку, которая незаметно подключается к исследуемой сети и передает собранные данные. Этот концепт вполне реализуем на Raspberry Pi.

Перевод статьи Аллана О’Доннелла Learning C with GDB.

Исходя из особенностей таких высокоуровневых языков, как Ruby, Scheme или Haskell, изучение C может быть сложной задачей. В придачу к преодолению таких низкоуровневых особенностей C, как ручное управление памятью и указатели, вы еще должны обходиться без REPL. Как только Вы привыкнете к исследовательскому программированию в REPL, иметь дело с циклом написал-скомпилировал-запустил будет для Вас небольшим разочарованием.

Недавно мне пришло в голову, что я мог бы использовать GDB как псевдо-REPL для C. Я поэкспериментировал, используя GDB как инструмент для изучения языка, а не просто для отладки, и оказалось, что это очень весело.

Идея о постройке квадрокоптера обуревала меня уже год назад. Но как обычно бывает (по крайней мере у меня) идея-фикс, которую не можешь никак выгнать из головы улетучивается, стоит только переждать пару дней. Таких приступов с летающей техникой у меня было несколько. И последний из них был вызван этим постом.
Прочитав пост и комментарии я всё-таки решился на покупку комплектующих. Дело было поздно вечером, а точнее уже рано ночью (я решил, что запал на следующий день уже может пройти и мне будет жалко отдать 400$) и я забыл заказать пару мелочей, которые на следующий день дозаказал второй посылкой (которая, кстати, пришла раньше основной). И начались 20 дней ожидания.
Ещё во время ожидания посылки решил, что сделаю первую раму на скорую руку, т.к скорее всего всё равно разобью её. Идея была в простейшей раме — алюминиевые квадратные трубы и стеклотекстолит по центру.
И вот пришла большая посылка с кучей деталей.

(посвящается Марку Криспину 19.07.1956 — 28.12.2012)

Некоторое время назад в Яндекс.Почте появились сборщики писем по IMAP. В этом посте мы немного расскажем о двух важных почтовых протоколах — POP3 и IMAP — и о том, как они появились и используются в современных почтовых системах. Не всегда это так просто и очевидно, как ожидаешь от технологий, развивающихся уже почти 30 лет.

Начнём наш экскурс в историю протоколов, через которые вы каждый день получаете свою сотню писем.

Здравствуйте, Хабралюди.

Мал по-малу из моего опыта и наших проектов родилась небольшая библиотека для работы с моделями в джаваскрипте. Она так и называется — Model.js.

Я расскажу вам вкратце об этой библиотеке и этим постом запрашиваю обратную связь у тех, кто создавая сложные джаваскрипт-приложения, уже решает эту проблему каким-то определенным образом без фреймворков. Интересно также и мнение тех, кто только подыскивает подходящий инструмент для своих нужд: какой инструмент вам нужен и насколько вам подходит Model.js?

В данной статье я постараюсь познакомить вас с замечательными утилитами Vagrant и Chef на примере автоматического конфигурирования development environment для PHP разработчика (на самом деле, PHP здесь только как пример, все нижеописанное может быть использовано для любого стека технологий).

Что будем делать?

Будем настраивать виртуальную машину (ВМ) с Ubuntu 12.04 для работы над проектом на PHP, а именно:

• Apache
• MySql
• PHP 5.4
• xDebug
• Memcached
• Composer
• Настроим сразу Virtual Host на определенную папку, доступную как с виртуальной машины, так и с реальной. Всё это параметризируем для удобства создания и использования.
• и другое..

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

Как это может помочь вам?

• Вы не хотите «засорять» свою систему множеством утилит, программ
• Вы хотите тестировать свой код в приближенных к production условиях
• Вы хотите тестировать свой код на разных версиях той или иной платформы (помните, как Travis тестирует билды в различных конфигурациях, например Symfony на разных версиях PHP)
• Вы не хотите больше помогать новому человеку на проекте (верстальщик, программист) устанавливать всё с нуля
• Вы хотите, чтобы у каждого человека в команде была идентичная среда для работы над проектом

Всё это — реальность. Вопрос только «как?».

Данная статья написана в форме поста для блога. Если она окажется вам интересной, то будет продолжение.

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

Общая задумка (пока весьма далёкая от реализации) следующая: единое 64-битное адресное пространство с вечно живущими нитями (как у Phantom OS); виртуальная машина, обеспечивающая безопасность исполнения кода. На данный момент реализованы:

1. загрузка ядра при помощи multiboot-загрузчика (GRUB);
2. текстовый VGA-режим (16-цветов, kprintf);
3. простой интерфейс настройки отображения страниц;
4. возможность обработки прерываний на C;
5. идентификация топологии процессоров (сокеты, ядра, потоки) и их запуск;
6. работающий прототип вытесняющего SMP-планировщика с поддержкой приоритетов;

Пропустим описание multiboot-загрузки и работы с VGA-режимом (об этом не писал, разве что, ленивый). Про отображение страниц тоже не хочу писать, боюсь это будет скучно (может, в другой раз). Давайте лучше поговорим об обработке прерываний.

Продолжаю вести блог о разработке игрушечной ОС.

В прошлом посте я писал о том, как добиться возможности реализовывать на C обработчики прерываний. Теперь, пользуясь написанными ранее макросами, можно реализовать простой SMP-планировщик. Он будет предоставлять минимально возможный функционал, на базе которого в будущем нужно будет возводить различные надстройки, в частности, примитивы синхронизации (например, мьютекс). Опять же, красивая модульная структура не способствует высокой производительности, но красота, как известно, спасёт мир, так что отдадим ей предпочтение.

Итак, попробуем сформулировать требования к нашему планировщику. Нам нужна возможность создать поток, указать для него стек, маску разрешённых логических процессоров (affinity), базовый приоритет и функцию выполнения. Далее, поток можно запустить, приостановить, продолжить его выполнение и, наконец, завершить.

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

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

У моего проекта несколько зависимостей. Бóльшая часть зависимостей живет в гитовых репозиториях. Сам проект тоже живёт в гите.

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

Раньше я просто копировал зависимости в папку проекта, и добавлял к каждой файл VERSION.TXT с её версией. Но, если нужно работать с текущей версией стороннего кода, это неудобно. Да и копировать файлы руками когда есть гит как-то глупо. Хочется найти более современное решение.

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