Construct спонсировал этот пост.
Ранее в этом году наша команда начала тайно работать над новым металлическим продуктом под названием Colony. В то время наша компания называлась Kubefirst, брендом, поделившейся с нашей популярной платформой Kubefirst. С добавлением линейки продуктов Colony пришло время переименовать нашу компанию в Construct.
С тех пор, как мотивация ребренда была разработана в тайне, она дала нам аккуратную возможность в секрете нашей новой компании. Как компания с открытым исходным кодом, создание новой организации в секрете было действительно забавным вызовом для нашей инженерной команды.
В конце концов, мы были пойманы одним членом нашего сообщества всего за несколько дней до нашего большого объявления. Выполнение нашего нового бренда и компании имела огромный успех, и мы хотели поделиться тем, как мы это сделали для вашего следующего переименного стенда.
Выбор более простого облака, чтобы позвонить домой
В течение последних пяти лет мы управляли нашей производственной средой на Kubefirst в облаке AWS. AWS был первым облаком, которое поддерживала наша платформа Kubefirst. Фактически, Kubefirst поддержал Kubernetes на AWS до того, как даже существовала служба Elastic Kubernetes (EKS). AWS был невероятно надежным для нас, и это был отличный дом, чтобы повесить наш Yaml на полдень.
С тех пор, как мы начали выращивать инженерную команду два года назад, наша платформа расширилась, включив поддержку GCP, Azure, Civo, Akamai, Digitalocean, Vultr и Bare Metal. Это дало уникальную возможность выбрать любое облако для размещения нашей переименованной экосистемы Construct. Мы использовали Civo Cloud в качестве среды развития в течение последних двух лет, и нам понравилась простота и скорость его облачного нативного подхода. В конце концов мы решили сделать Civo нашим новым постоянным производственным домом, и пришло время открыть магазин.
Секретный контрольный список движения
- GIT Organization размещает наши открытые и закрытые кодовые базы
- Публично размещены бинарные файлы CLI
- Общедоступные диаграммы
- Общественные контейнерные изображения
- Публичный домашний кран
- DNS (был AWS Route53, мигрировал в CloudFlare)
- Наше внутреннее управление (пользователи, команды, разрешения и репозитории GIT)
- Наша экосистема CI и доставки (Argo Workflows + Github actions)
- Наша плоскость управления кластером (Kubefirst + Crossplane + Atlantis + Argo CD)
- Самостоятельный маркетинговый сайт (React), сайт DOCS (Docusaurus) и блог (Призрак)
Подготовка учетных записей бота
Мы настроили наш домен construct.io в CloudFlare с новой учетной записью BOT для нашей автоматизации. Мы создали ключ API для новой платформы, чтобы автоматически управлять записями DNS.
Далее мы создали новую учетную запись пользователя GitHub Bot для создания и управления нашей новой организацией Konstruct.io Github и токеном личного доступа для инфраструктуры платформы в качестве уровня кода (IAC). Если бы не операция Stealth, мы могли бы просто переименовать нашу организацию GitHub для автоматического перехода репозиториев. Однако в секретной операции ваши частные репо должны перемещаться до того, как ваши публичные репо, поэтому полная организация становится менее оптимальной.
Последняя учетная запись BOT, которую мы создали, была новой учетной записью Civo Cloud, из которой мы сгенерировали токен API, позволяющий платформе управлять нашими облачными ресурсами.
День строительства
Есть что -то настолько освежающее в создании вашей новой учетной записи управления. Никогда ни один человек. Сделайте глубокий вдох. Вы можете почувствовать запах стерильного воздуха здесь?
Благодаря экспортированию нашего нового набора ключей мы запустили Kubefirst Civo Create, чтобы построить нашу платформу Kubefirst, Mint Condition, в совершенно ином облачном опыте. Он использовал нашего любимого нового поставщика DNS с свежеприготовленным репозиторием Gitops, созданным для нас и помещена в нашу новую организацию GitHub.
Далее нам нужно было создать новые кластеры для представления нашей среды предварительного и производства. Для кластеров мы использовали пользовательский интерфейс Kubefirst Pro для их создания. Мы скопировали каталог окружающей среды из нашего Old Gitops Repo в наш новый репо -репо, и CD Argo гарантировал, что все диаграммы Helm были благополучно доставлены в их новый дом.
В сценарии, в котором вы мигрируете поставщиков облаков, поставщиков DNS и организаций GIT, вам нужно будет обновить некоторые старые значения, когда вы передаете контент репозитория в его новый дом. Будьте внимательны к любым ссылкам на вашу старую организацию GIT или свои старые имена хостов DNS при копировании этих настроек.
Внося эти изменения, CD ARGO является отличным пространством для оценки для состояния и здоровья вашего кластера. CD Argo часто сообщает вам проблему, всплыв ошибку через события в пользовательском интерфейсе. В нашем случае это были в основном несколько секретов из старой среды, которые нам нужно было воспроизвести в новой среде.
Изображение 1
Один за другим мы очистили эти проблемы, и платформа перешла к этому сердцу CD Argo, которое мы учимся любить.
Мигрирующие диаграммы в экземплярах chartmuseum
У нас был сложный нюанс, чтобы рассмотреть с помощью нашего хостинга. Мы принимали наши диаграммы в Chartmuseum, поэтому наш новый экземпляр начался пустым. Все, что будет опубликовать его автоматически, но мы хотели заполнить его со всеми существующими графиками Kubefirst, чтобы люди могли полностью переключиться на наш новый репозиторий диаграммы, когда мы были готовы.
Если вы знаете что -нибудь о Chartmuseum, вы можете подумать, что вы можете просто скопировать ведра и обновить index.yaml, но это сложнее, чем это. Для этой миграции не было ничего особенно хорошего в Интернете, поэтому мы написали новую утилиту с открытым исходным кодом, чтобы помочь людям сделать это. Если вам когда-нибудь понадобится резервное копирование или мигрирование картмузеума, возьмите нашу графическую репо-репо. Это позволит вам перемещать диаграммы между чартмуземинспинсами и позволит вам резко и восстановите диаграммы между чартмузеумом и GitHub для целей аварийного восстановления.
Мигрирующий IAC
Kubefirst управляет нашими облаками, пользователями, конфигурациями хранилища и конфигурациями GIT с использованием IAC, а для всего остального мы используем Gitops. Все четыре из этих каталогов создаются с настройками по умолчанию при создании платформы Kubefirst, но мы хотели вместо этого перенести наш оригинальный контент Kubefirst.
- Облако: Облачному МАК не нуждалась в каких -либо корректировке. Мы в новом облаке, поэтому нечего двигаться.
- Пользователи: Мы смогли скопировать эти файлы прямо в новом филиале. Наша запрос на привлечение побудила Atlantis предоставить план, который нам понравился; Мы добавили комментарий Atlantis, и Boom, наши пользователи находятся в своем новом доме. На данный момент приглашенные выступили со всей нашей командой об их новом доступе GIT Org, и каждый мог использовать новую платформу и войти во все свои любимые инструменты платформы в своем новом облаке. Все было отлично.
- Сейф: Это не требовало корректировки. Конфигурации по умолчанию отлично подходят для нашей команды.
- Githubub: Это был сложный. Давайте поговорим об этом дальше.
Мигрирующие репозитовы GitHub в режиме стелса
Это было, вероятно, самым сложным для нас, чтобы получить право. Мы управляем нашими репо с помощью Atlantis в нашем старом кластере управления, и все было создано в оригинальной Org Kubefirst, где мы начали.
Мы хотели перенести наши репозитории в нашу новую Org Constructio, но мы еще не хотели чаевать наши карты ребрендинга. Это означало, что для нашей кодовой базы открытого исходного кода ничто не может измениться до последней минуты.
Для всех наших репо с закрытым исходным кодом мы просто скопировали файлы из нашей старой папки Terraform/Github в нашу новую. Когда запрос на притяжение было открыто, план читается так, как будто он создаст все новые репо.
Мы перевели каждое из частных репо в Орг Кинструктио, а затем управляли импортом Атлантиды для каждого репо, поэтому его состояние будет унаследовано новым МАК. Затем мы переоцениваем, что Атлантида планирует не показать никаких изменений. После применения мы все были синхронизированы на частной миграции репо.
Для наших репозиториев с открытым исходным кодом мы сделали новые копии их в публичном неизвестном месте Конструктио, эффективно дублирующего наши существующие общественные репо. Это дало нам возможность определить изменения, так как мы проверили наши конвейеры публикации и доставки и обеспечили бы все, что было готово построить и опубликовать наши продукты из их нового дома.
Это тестирование представило нашу единственную ошибку: Homebrew.
Домашние соображения
Homebrew не хотел помогать нам сохранить наш секрет. Дублируя нашу публичную домашнюю репо, мы разоблачили наши планы.
Homebrew Tap Repos автоматически обнаруживается при создании репо в GitHub. Если они настроены на новое пространство, они могут следовать за перенаправлениями и наблюдать за вашими новыми общественными репонировать при их передаче.
Это была единственная деталь, которая показала нашу руку перед объявлением. Некоторые из наших новых кандидатов на релиз начали появляться, прежде чем мы захотите в старом кране из -за правил пересылки GitHub. Будьте внимательны к конфигурациям домашнего пиво и перенаправления репо во время миграции, если вы также поддерживаете домашний кран.
День миграции
С нашими частными репо в их новом доме мы гарантировали, что они могут построить и доставить в новый реестр контейнеров, реестр диаграмм и кластеров Kubernetes. Мы проверили CD Argo в последний раз, чтобы убедиться, что все приложения были здоровы без ошибок. Все, что можно было бы настроить до того, как была сделана последняя партия перемещений репо, прослушивая его новый домен и здоровье.
Когда пришло время для большой смены, мы перенесли все оставшиеся git args, в том числе все репо с открытым исходным кодом, особенно осторожные со всеми щелчками, окружающими наши звезды Github 1900. Если вы случайно сделаете репо -частное — или копировать вместо того, чтобы перенести репо — вы не останетесь в том, что вы потеряете этот важный показатель тщеславия.
Не забудьте поддерживать защиту от seo
Одна деталь, которая легко ошибаться после смены домена, — seo. До тех пор, пока ваш оригинальный бренд и домен жили в Интернете, Google и другие развертывают seo -роботов для чтения и индекса соответствующего контента для пользователей. Вы захотите убедиться, что вы не теряете seo -след, окружающий ваш оригинальный домен. Вот некоторые идеи, которые могут помочь, если вы решите обновить.
При изменении доменов полезно изменить как можно меньше слов и страниц. Это плохое время, чтобы ввести новые документы или изменить технологии блогов, если вы можете избежать этого. Мы все равно сделали оба и жили, чтобы рассказать историю. Сохранение активов и местоположений такими же поможет вам убедить роботов, что вы та же самая компания и все еще достойны репутации seo, которую вы создали на своем старом домене.
Подписка на что -то вроде AHREFS для исследований обратных ссылок может помочь вам найти все ссылки, которые разорвались от вашего смены домена. Важно исправить разбитые ссылки, обновляя их исходный исходный контент, если вы можете, или добавив перенаправления в вашу конфигурацию DNSHOSTING, когда вы не можете. Перенаправления позволит вам прислать плохие ссылки на свои новые хорошие дома, чтобы успокоить роботов. Наше обновление в CloudFlare DNS сделало управление перенаправлением очень простым. Google Search также имеет несколько хороших инструментов миграции доменов, которые могут помочь.
После того, как вы подтвердили, что весь трафик перестал перетекать к вашим первоначальным источникам, и все необходимые перенаправления перенаправляют конечных пользователей в свой новый дом, вы можете безопасно снести старый мир и полюбоваться своей собственной переносимостью облака.
Объявление о своем величии миру
Поздравляю, вы добрались до своего нового домена! Теперь пришло время пригласить всех ваших публичных пользователей в ваш новый цифровой дом.
Возможность изменить DNS, GIT и облачные провайдеры может быть большой работой для многих компаний, но для Construct это было не сложно, потому что мы используем Kubefirst.
Kubefirst является агностиком для поставщиков Cloud, GIT и DNS, так что вы можете иметь ту же платформу в любом месте. Сколько времени потребуется вашей организации, чтобы изменить облака, git orgs или поставщики DNS? Проверьте наши обзорные документы, чтобы узнать больше о нашей магии мгновенного пакета, или забронируйте со мной демо, чтобы получить быстрый тур сегодня.
Construct выполняет миссию по демократизации уроженцев облака и расширяет возможности организаций контроля и мобильности над технологиями, которые стимулируют их бизнес. Мы помогли сотням компаний преобразовать современное управление приложениями и инфраструктурой с нашими нативными платформами мгновенных облаков. Узнайте больше последних из Construct Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Джон Дитц является генеральным директором Construct и управляет видением продуктов Kubefirst и Colony с момента основания компании. Его миссия состоит в том, чтобы предоставить миру мгновенные платформы Gitops с открытым исходным кодом в любом облаке … Подробнее от Джона Дитца
