Трохи більше ніж рік тому, Я приєднався до Фундації OpenStreetMap (OSMF) з метою підвищення надійності та безпеки технологій та інфраструктури, що лежать в основі OpenStreetMap. Протягом останнього року я тісно співпрацював з Операційною Робочою групою, відданою командою волонтерів. Разом ми досягли значного прогресу в удосконаленні наших процесів і документації, що в кінцевому підсумку зміцнило нашу колективну ефективність. Я безмежно вдячний за підтримку та співпрацю з цією групою, і я радий бути свідком чудових успіхів, які ми зробили у створенні міцної основи для майбутнього OpenStreetMap.
Нижче я детально розповім про те, що сталося. На високому рівні я полегшив управління розгортанням програмного забезпечення, що працює на наших серверах; зміцнили нашу мережеву інфраструктуру за рахунок кращого резервування, моніторингу, доступу та документації; розширив наше використання хмарних сервісів для рендерингу тайлів, використовуючи щедру спонсорську підтримку від AWS; було удосконалено наші практики стосовно безпеки; оновлено середовище для розробників; І останнє, але, безумовно, не менш важливе: завершена міграція 16-річного контенту з наших старих форумів на наші нові форуми.
Якщо ви хочете почути більше від мене про роботи виконані минулого року, перегляньте мій виступ на State of the Map 2022 and моє інтервʼю подкасту GeoMob. Я із задоволенням відповім на ваші листи osmfuture@firefishy.com.
2022-2023 Інформація стосовно надійності сайту
Управління програмним забезпеченням на наших серверах
Контейнеризовані невеликі інфраструктурні компоненти (з допомогою GitHub Actions)
Я контейнеризував багато наших невеликих сайтів, які раніше були побудовані за допомогою індивідуальних методів у нашій кодовій базі chef в рамках підходу “Конфігурація як код”. Перемістив етап збірки в Github Actions. Створив базу для будь-яких майбутніх проєктів на основі контейнерів (“docker”). Це наші перші контейнерні/докерні проєкти, розміщені на інфраструктурі OSMF.
Наш код на основі chef тепер простіший, безпечніший і розгортається швидше.
Покращене тестування chef-сценаріїв (документація з адаптації операцій)
Ми використовуємо chef.io для управління інфраструктурою (конфігурацією) всіх наших серверів і програмного забезпечення на них. За останній рік тести Chef Test Kitchen були розширені й тепер також працюють на компʼютерах з Apple Silicon. Тести тепер надійно виконуються в рамках наших процесів CI / PR. Тести додають контроль якості та гарантію якості змін, які ми вносимо. Додавання підтримки ARM було легше додати, оскільки ми могли використовувати test kitchen, перш ніж перейти на серверне обладнання ARM.
Наявність надійних тестів має допомогти залучити нових учасників в управління chef.
Зміцнили нашу мережеву інфраструктуру
Оновлення мережі @ AMS (нові комутатори, подвійні резервні канали, Дублін незабаром)
Наша мережа в Амстердамі не була такою надмірною, як мала б бути. Обладнання Cisco Small Business, яке ми використовували, ми переросли. У нас були несподівані відключення електроенергії через проблеми з обладнанням. Обладнання також обмежувало майбутні модернізації. Операційна група вирішила замінити апаратне забезпечення на обладнання Juniper, яке ми стандартизували в дублінському центрі обробки даних. Я замінив обладнання з мінімальним часом простою в живому середовищі (<15 хвилин).
Обидва центри обробки даних у Дубліні та Амстердамі тепер використовують стандартизовану та більш безпечну конфігурацію. Кожен сервер тепер має повністю багатоканальні зʼєднання для покращення резервування та продуктивності. Комутатори мають покращену потужність та мережеве резервування. Ми очікуємо на встановлення повністю стійких аплінків (замовлення подано) наступного місяця.
Out-of-Band (OOB) доступ до обох центрів обробки даних (на основі 4G)
Я створив і встановив пристрої “доступ поза каналом” на кожній локації. Пристрої напряму підключені до мережевого обладнання та обладнання управління живленням за допомогою консолей. Пристрої Out-of-Band (OOB) доступу мають стійке зʼєднання 4G з приватною мережею 4G (1NCE). Пристрої позасмугового доступу — це спеціально побудовані пристрої на базі Raspberry PI з резервними джерелами живлення та 4-ма послідовними портами.
Документація інфраструктури для простоти обслуговування (Стійки / Живлення)
Я задокументував кожен блок стійки, порт живлення (блок розподілу потужності), підключення до мережі та кабелів у центрах обробки даних. Це полегшує управління серверами, зменшує кількість помилок і дозволяє нам належним чином інструктувати віддалений персонал (зовнішнього постачальника підтримки) щодо внесення будь-яких змін від нашого імені.
Oxidized (видимість мережевого обладнання)
Наша конфігурація мережі та розподілу потужностей тепер зберігається у git, і про зміни повідомляється. Це покращує видимість будь-яких змін, що, своєю чергою, підвищує безпеку.
Налаштування постійно контролюються, і будь-який дрейф конфігурації між нашими сайтами тепер набагато легше вирішити.
Інфраструктура Terraform як код (покращення управління / повторюваність)
Terraform — це інструмент інфраструктури як коду, зараз ми використовуємо його для керування нашою службою віддаленого моніторингу (статусний пиріг), і я перебуваю в процесі його впровадження для управління нашою інфраструктурою AWS та Fastly.
Раніше всі ці компоненти керувалися вручну за допомогою відповідних вебінтерфейсів. Інфраструктура як код дозволяє команді Ops спільно працювати над змінами, покращує видимість і повторюваність / відкат будь-яких змін.
Управляємо всіма доменами DNS за допомогою коду dnscontrol. За останній рік були зроблені поступові поліпшення, включаючи додавання тестів CI для поліпшення співпраці.
Розширилося використання хмарних сервісів
AWS використовується для рендерингу тайлів. Оптимізовані витрати на AWS. Покращено безпеку. Покращено резервування. Детальніше про конвеєризацію
Команда Ops повільно збільшувала використання AWS протягом кількох років. Я створив кілька облікових записів AWS для конкретного використання, використовуючи модель організації AWS, щоб покращити виставлення рахунків та безпеку відповідно до рекомендацій щодо найкращих практик AWS. Ми отримали щедру спонсорську підтримку від AWS для розширення нашої інфраструктури рендерингу. Ми побудували експериментальну нову інфраструктуру рендерингу з використанням архітектури ARM за допомогою AWS Graviton2 EC2.
Ми раніше не використовували сервери на базі ARM. У рамках удосконалення нашого інструментарію chef (конфігурація як код) ми додали локальну підтримку тестування Apple Silicon (ARM), потрібні були лише невеликі доповнення, щоб додати необхідну сумісність для серверів ARM для chef.
Ми були вражені продуктивністю екземплярів AWS Graviton2 EC2 для запуску стека рендерингу тайлів OSM. Ми також протестували масштабування на вимогу та створення копій екземплярів для потенційних подальших покращень стека на AWS.
Ми збільшили використання AWS для резервного копіювання даних.
Покращення нашої безпеки
За останній рік було зроблено ряд загальних покращень безпеки. Наприклад: Доступ до сервера тепер здійснюється за допомогою ключа ssh (доступ за допомогою пароля тепер вимкнено). Ми також перейшли від індивідуального менеджера паролів на основі gpg для Операційної робочої групи до використання gopass (багатофункціональна версія https://www.passwordstore.org/ ), Gopass покращує керування ключами та обмін паролями.
Крім того, ми також посилили блокування наших екземплярів WordPress, зменшивши кількість встановлених компонентів, вимкнувши вбудовані оновлення та вимкнувши доступ XMLRPC. Ми також працюємо над зменшенням кількості користувачів із доступом і видаленням дозволів доступу, які не використовуються.
Задокументовані ключові області вразливості, які потребують покращення (надмірність, безпека тощо)
Документація щодо технічної вразливості: Я готую звіт про ключові області вразливостей, що потребують вдосконалення (надмірність, безпека тощо). Цей документ можна використовувати, щоб зосередити інвестиції в майбутньому для подальшого зменшення ризиків.
Оновлено середовище розробників
Новий сервер розробників
Минулого року ми перенесли всіх облікові записи розробників на новий сервер. Термін служби старого сервера закінчився (приблизно 10 років), і його ємність (ЦП і сховище) вичерпувалася. Новий сервер був доставлений безпосередньо до дата-центру в Амстердамі, фізично встановлений віддаленим персоналом, а я здійснив процес міграції, сповістивши про неї, і потім перемістив усіх користувачів та проєкти.
Subversion відправлено на покій
Наш старий сервер контролю версій svn.openstreetmap.org було відключено минулого року. Сервер контролю версій використовувався з моменту створення проєкту, він містить багату історію розробки коду в проєкті. Я перетворив репозиторій коду svn на git за допомогою власних налаштувань reposurgeon, було приділено увагу підтримці повної історії внесків та правильному звʼязуванню попередніх учасників (350+) з відповідними github та іншими повʼязаними обліковими записами. Старі посилання svn були збережені і тепер посилаються на архів на github https://github.com/openstreetmap/svn-archive
Міграція форуму
Міграція старого форуму, ми перенесли 1 мільйон постів і 16 років постів на платформу дискурс. Всі пости були перетворені з fluxbb у markdown варіант, з яким працює дискурс. Всі облікові записи були обʼєднані, а процес авторизації переведено на використання авторизації OpenStreetMap.org.
Всі посилання на пости на старому форумі тепер є перенаправленнями на відповідні пости на дискурс. Користувачі, категорії (країни тощо), Ланцюжки тем та окремі публікації.
