詳細検索

Migrando de Azure App Service para Azure Kubernetes Service com nossos próprios serviços vol.3

Avatar
por Kohei Akiyama
2 min de leitura

Migrando de Azure App Service para Azure Kubernetes Service com nossos próprios serviços vol.3
Traduzido do 日本語 • Ver original

Olá. Aqui é Akiyama do Azure Cloud Solution Architect. Desta vez, continuarei escrevendo sobre a história da migração para o k8s no nosso Mamoru Biz .

移行をどのように進めたかについて書きます。 まずは移行のスコープの検討です。

移行の進め方

今回の移行では Azure インフラの置き換えが主であり、例えばアプリケーションが動作している Docker コンテナについてはこれまでのものをそのまま k8s 上で動かすことにしました。 (Mamoru Biz では Docker イメージを管理しているのは基本的にアプリケーションエンジニアです。)

これは、できる限りインフラエンジニアがコントロール可能な範囲で移行を進めるための措置です。 (実際には k8s 上で動くようになった後に App Service 向けにカスタマイズしていた Docker コンテナを修正する、ということも追って対応しました。)

移行のスコープ

移行のメインターゲットは App Service ですが、 AKS(k8s) で代替可能な機能は置き換えることを計画していました。 Vol.1 .

Além do Container Instance, havia também um trabalho que usava a Request HTTP do Logic App para rodar a API Web do Administrador. Essas funções também estão sujeitas a migração porque é desejável que os desenvolvedores possam criá-las por conta própria.

Quando tivemos o maior escopo em mente, seguimos o Princípio de Pareto quando realmente avançamos, e a parte principal foi o escopo do primeiro lançamento. Esse escopo foi ajustado conforme o projeto avançava, e acabamos com o primeiro lançamento com um escopo menor do que havíamos considerado.

Como resultado, não houve problemas durante a migração, mas acho apropriado lançar várias vezes em unidades pequenas para minimizar problemas quando surgiam.

k8s migration scope

Construa um ambiente de infraestrutura Azure

Ao construir o ambiente, temos usado o Terraform desde antes deste projeto de migração para minimizar as diferenças entre os três ambientes de desenvolvimento, staging e produção.

Esta é uma medida para evitar problemas como "a aplicação não consegue acessar o banco de dados no ambiente de staging (mesmo que estivesse ok no ambiente de desenvolvimento), e a configuração do firewall é insuficiente".

O Terraform é usado como ambiente de execução para o Terraform . No geral, estou satisfeito, e uma coisa que posso mencionar é que a função de Controle de Acesso é útil. O Mamoru Biz limita os ambientes em que o 'terraform apply' pode ser executado de acordo com o nível de proficiência do Terraform e o grau de compreensão do ambiente dos engenheiros de infraestrutura.

Desenvolvendo um Ambiente DevOps

Mencionamos DevOps de infraestrutura anteriormente, mas o ambiente DevOps na camada k8s precisava ser mantido por meio deste projeto.

Aliás, o App Service usou as funções suportadas para trocar os containers como estavam. Referência: Implantação contínua usando containers personalizados no Azure App Service Sou grato que essa área é bem tratada.

Para a camada k8s, usamos GitHub Actions . Ele detecta mudanças nos manifestos k8s e as aplica ao AKS.

k8s deploy

Usamos o Helm para implantação.

Embora o ambiente DevOps tenha facilitado o lançamento, esse mecanismo ainda precisa ser melhorado tanto em operações quanto em velocidade em comparação com as implantações na era dos Serviços de Aplicativos.

Conclusão

Até agora, dividimos em três artigos e apresentamos o projeto que migrou nosso serviço Mamoru Biz do App Service para o AKS (k8s). Embora a migração já tenha sido concluída, continuaremos trabalhando em pequenas melhorias para oferecer aos clientes um nível maior de serviços de "redução de trabalho sem nome".

Por último, mas não menos importante,

Na Colorkrew, você pode experimentar tanto o desenvolvimento dos seus próprios serviços quanto o negócio de contratos. Se você tem interesse em nossa empresa, por favor, insira na página de recrutamento .

Se você tem interesse em apoiar a introdução de um sistema configurado por contêiner, entre em contato conosco abaixo. Suporte à Implementação de Serverless/Contêiner |

Related Articles