В кінці липня 2016 року в корпоративному блозі Über з'явилася воістину історична стаття про причини переходу компанії з PostgreSQL на MySQL. З тих пір в жарких обговореннях цього матеріалу було зламано чимало списів, аргументи Über були ретельно препаровані; компанію звинуватили в упередженості, технічної неграмотності, нездатності ефективно взаємодіяти з спільнотою та інших смертних гріхах, при цьому по гарячих слідах Postgres було внесено кілька змін, покликаних вирішити деякі з описаних проблем. Список наслідків на цьому не обмежився, і його можна продовжувати ще дуже довго.
Напевно, не буде перебільшенням сказати, що за останні кілька років це було одне з найбільш гучних і резонансних подій, пов'язаних з СУБД PostgreSQL, яку ми, до речі сказати, дуже любимо і широко використовуємо. Ця ситуація напевно пішла на користь не тільки згаданим систем, але і руху Free and Open Source в цілому. При цьому, на жаль, російського перекладу статті так і не з'явилося. Зважаючи на значущість події, а також докладного і цікавого з технічної точки зору викладу матеріалу, в якому стилі Postgres vs MySQL йде порівняння фізичної структури даних на диску, організації первинних і вторинних індексів, реплікації, MVCC, оновлень і підтримки великої кількості сполук, ми вирішили заповнити цей пробіл і зробити переклад оригінальної статті. Результат ви можете знайти під катом.
Читати далі →



Розроблена інженерами Über система зберігання даних Schemaless використовується в декількох найважливіших і великих сервісах нашої компанії (наприклад, Mezzanine). Schemaless — це масштабоване та надійне сховище даних, що працює поверх кластерів MySQL1. Коли цих кластерів було 16, керування ними була нескладною справою. Але зараз у нас їх понад 1 000, і в них розгорнуто не менше 4 000 серверів баз даних. Управління такою системою вимагає інструментів зовсім іншого класу.
З безлічі компонентів, що входять до Schemadock, порівняно невеликий, але дуже важливою частиною є Docker. Перехід на більш масштабоване рішення став для нас знаковою подією, і в даній статті ми розповіли про те, як Docker допоміг нам цього домогтися.
Читати далі →

Kamailio SIP proxy: приклад установки і мінімальної налаштування


В роботі системного адміністратора, що займається впровадженням систем телефонії на базі Asterisk, рано чи пізно може виникнути ситуація, коли апаратних можливостей одного сервера для обробки всіх викликів вже недостатньо. Відповідно, виникає необхідність розділити навантаження на декілька серверів. Одним із способів вирішення такого завдання є використання SIP proxy, але варто визнати, що на відміну від Asterisk, інформації по SIP proxy, форумів, прикладів і описів, менше як мінімум на порядок. Мета цієї статті — показати на простому прикладі можливість використання SIP proxy Kamailio в зв'язці з Asterisk так, щоб максимально полегшити освоєння SIP proxy для новачків.

Читати далі →

Використання GlusterFS з кластером Docker swarm


У цій статті я описав створення в AWS складається з трьох нод кластера Docker Swarm і підключення до нього спільного для всіх нод реплицируемого тома GlusterFS.
Читати далі →

sudo rm -rf або хроніка інциденту з базою даних GitLab.com від 2017/01/31


Він п'янів повільно, але все-таки сп'янів, як-то відразу, стрибком; і коли в хвилину просвітління побачив перед собою розрубаний дубовий стіл в абсолютно незнайомій кімнаті, оголений меч у своїй руці і плеще в долоні безгрошових донів навколо, то подумав, що пора йти додому. Але було пізно.

Аркадій і Борис Стругацькі
31 січня 2017 року відбулася важлива для світу OpenSource подія: один з адмінів GitLab.com, намагаючись полагодити реплікацію, переплутав консолі і видалив основну базу PostgreSQL, в результаті чого було втрачено велику кількість даних, і сам сервіс пішов в офф-лайн. При цьому всі 5 різних способів бекапа/реплікації виявилися неробочими. Відновилися ж з LVM-знімка, випадково зробленої за 6 годин до видалення бази. It, як кажуть, happens. Але треба віддати належне команді проекту, так як вони знайшли в собі сили поставитися до всього з гумором, не втратили голову і проявили дивовижну відкритість, написавши про все в твіттері і виклавши в загальний доступ, по суті, внутрішній документ, в якому команда в реальному часі вела опис розгортаються подій.
Під час його читання буквально відчуваєш себе на місці бідного YP, який в 11 годин вечора після важкого трудового дня і безрезультатної боротьби з Постгресом, стомлено мружачись, вбиває в консоль бойового сервера фатальне
sudo rm -rf
і тисне Enter. Через секунду він розуміє, що накоїв, скасовує видалення, але вже пізно — бази більше немає...
З причини важливості і в багатьох сенсах поучительности цього випадку, ми вирішили повністю перевести на російську мову його журнал-звіт, зроблений співробітниками GitLab.com у процесі роботи над інцидентом. Результат ви можете знайти під катом.
Читати далі →

Підвищуємо безпеку контейнерів Docker



— Пане, яким чином вас зламали?
— Не спосіб, а контейнером.
Старовинний анекдот
Всі зайві компоненти комп'ютерної системи можуть виявитися джерелом зовсім необов'язкових вразливостей. Тому образи контейнерів повинні містити тільки те, що потрібно додатком. І їх розмір має значення не тільки з точки зору зручності дистрибуції, а також вартості володіння і безпеки. У цій статті ми поговоримо про методи мінімізації розміру і поверхні атаки образів Docker, а також про інструменти їх сканування на предмет наявності вразливостей.
Читати далі →

Уроки року боротьби з порушеннями інформаційної безпеки



У 2016 році у мене було дуже багато завдань, пов'язаних з реагуванням на інциденти інформаційної безпеки. Я витратив на них в загальній складності близько 300 годин, самостійно виконуючи необхідні дії або консультуючи фахівців постраждалої сторони. Матеріалом для статті послужили мої записи, зроблені в процесі цієї роботи.
Читати далі →

Техпідтримка в епоху DevOps




DevOps йде у великі ІТ-компанії незалежно від того, готові вони до цього чи ні. Тут може зустрітися багато проблем, і я хотів би поговорити про одну з них. Можливо, це занадто смілива заява, але я вважаю, що поточна організаційна структура більшості служб ІТ-підтримки в корені хибна.
У такій ситуації успішне впровадження DevOps-практик може виявитися практично неможливим.
В якості альтернативи я хотів би запропонувати нову методологію під назвою Swarming, яка вже готова до впровадження у великому бізнесі і ідеально підходить для виконання завдань технічної підтримки в еру DevOps.
Читати далі →

Slow Cooker: навантажувальне тестування мережевих сервісів


Linkerd, наша сервісна сітка (service mesh) для хмарних додатків, з обов'язку служби зобов'язана протягом тривалого часу справлятися з великими обсягами мережевого трафіку. Перед випуском чергового релізу відповідність цій вимозі необхідно ретельно перевіряти. У цій статті ми опишемо стратегії навантажувального тестування та використані нами інструменти, а також розглянемо кілька виявлених проблем. В результаті буде представлений slow_cooker — написаний на Go інструмент навантажувального тестування з відкритим вихідним кодом, який був створений для виконання тривалих навантажувальних тестів та виявлення проблем життєвого циклу (life cycle issue identification).
Читати далі →