Meu nome é Petr Zaytsev, sou CEO e fundador e quero contar:
- como passamos de soluções open source para Database as a Service;
- quais são as abordagens para implementar bancos de dados na nuvem;
- como o Kubernetes pode substituir o DBaaS, eliminando a dependência de fornecedores e mantendo a simplicidade do SGBD como serviço.
Este artigo foi preparado com base na apresentação no @Databases Meetup by Mail.ru Cloud Solutions & Tarantool. Se você não quer ler, pode assistir:
Como passamos de open source para Database as a Service na nuvem
Trabalho com open source desde o final dos anos 90. Vinte anos atrás, usar open source, como bancos de dados, não era tão simples. Era necessário baixar o código fonte, patchar, compilar e só então usar.
Depois disso, o open source passou por uma série de simplificações:
- códigos fontes Tar.gz e INSTALL que precisavam ser compilados;
- pacotes com dependências como .deb e .rpm, onde era necessário apenas instalar um conjunto de pacotes;
- repositórios de pacotes como APT e YUM, que permitem a instalação automática;
- soluções como Docker e Snap, que permitem obter pacotes por instalação sem dependências externas.
Como resultado, usar software livre se torna mais fácil, e a barreira de entrada para o desenvolvimento de tais aplicativos diminui.
No entanto, ao contrário da situação de 20 anos atrás, quando todos eram especialistas em compilação, a maioria dos desenvolvedores hoje não consegue compilar as ferramentas que utilizam a partir do código fonte.
Na verdade, isso não é ruim, pois:
- Podemos usar software mais complexo, mas mais amigável. Por exemplo, um navegador — é conveniente, mas contém muitos componentes open source e não é fácil compilar do zero.
- Mais pessoas podem se tornar desenvolvedores de open source e outro software, mais empresas utilizam software, e a demanda por ele aumenta.
O lado negativo — o próximo passo na simplificação está relacionado ao uso de soluções em nuvem, o que leva a um certo vendor lock-in, ou seja, dependência de um único fornecedor. Usamos soluções simples e provedores utilizam componentes open source, mas na prática estão presos a uma das grandes nuvens. Ou seja, a maneira mais simples e rápida de implantar open source (e software compatível) é na nuvem, utilizando APIs proprietárias.
Falando sobre bancos de dados na nuvem, existem duas abordagens:
- Montar a infraestrutura de banco de dados, como em um data center tradicional. Ou seja, pegar componentes padrão: computação, armazenamento e assim por diante, instalar Linux, um banco de dados e configurá-lo.
- Utilizar Database as a Service, onde o provedor oferece um banco de dados pronto dentro da nuvem.
Atualmente, o DBaaS é um mercado em rápido crescimento, pois esse serviço permite que os desenvolvedores trabalhem diretamente com bancos de dados e minimiza o trabalho rotineiro. O provedor assume a responsabilidade pela alta disponibilidade e escalabilidade fácil, aplicação de patches, backups e configuração de desempenho.
Dois tipos de Database as a Service baseados em open source e uma alternativa em forma de Kubernetes.
Há dois tipos de Database as a Service para bancos de dados abertos:
- Produto padrão open source, empacotado em um backend para administração, o que simplifica a implementação e gerenciamento.
- Solução comercial avançada com vários complementos, compatível com open source.
Ambas as opções reduzem a possibilidade de migração entre nuvens, diminuem a portabilidade de dados e aplicativos. Por exemplo, embora diferentes tipos de nuvens suportem essencialmente o mesmo padrão MySQL, existem diferenças significativas entre elas em termos de funcionamento, desempenho, backup e assim por diante. Migrar de uma nuvem para outra pode ser complicado, especialmente para aplicativos complexos.
E aqui surge a questão — é possível obter a conveniência do Database as a Service, mas como uma solução open source simples?
A má notícia é que, infelizmente, atualmente não há soluções desse tipo no mercado. A boa notícia é que existe o Kubernetes, que permite implementar tais soluções.
Kubernetes é um sistema operacional para nuvem ou data center que permite implantar aplicativos e gerenciá-los em múltiplos servidores de um cluster, em vez de em um único host.
Atualmente, o Kubernetes é o líder na categoria desse tipo de software. Para essas tarefas, existiram muitas soluções diferentes, mas foi ele que se tornou o padrão. Muitas empresas que antes trabalhavam em soluções alternativas agora estão se concentrando na adaptação de seus produtos para suportar o Kubernetes.
Além disso, o Kubernetes é uma solução versátil que é suportada em nuvens privadas, públicas e híbridas de muitos fornecedores, como: AWS, Google Cloud, Microsoft Azure, .
Como o Kubernetes funciona com bancos de dados
Kubernetes foi inicialmente desenvolvido para aplicativos stateless que processam dados, mas não armazenam nada, como microserviços ou aplicativos web. Bancos de dados estão do outro lado do espectro, ou seja, são aplicativos stateful. E o Kubernetes não foi originalmente projetado para tais aplicativos.
No entanto, existem recursos que foram adicionados ao Kubernetes recentemente e que permitem o uso de bancos de dados e outros aplicativos stateful:
- O conceito de StatefulSet é uma série de primitivas para gerenciar eventos de interrupção de pods e realizar um Graceful Shutdown (desligamento previsível do aplicativo).
- Persistent Volumes são repositórios de dados que estão associados a pods, objetos de controle do Kubernetes.
- Operator Framework — ou seja, a capacidade de criar componentes para gerenciar bancos de dados e outros aplicativos stateful distribuídos em vários nós.
Atualmente, existem grandes Database as a Service em nuvens públicas, cuja infraestrutura de backend é baseada em Kubernetes, por exemplo: CockroachCloud, InfluxDB, PlanetScale. Assim, ter um banco de dados no Kubernetes não é apenas uma possibilidade teórica, mas algo que funciona na prática.
A Percona tem duas soluções de código aberto para Kubernetes:
- Kubernetes Operator para Percona Server for MongoDB.
- Kubernetes Operator para XtraDB CLUSTER — um serviço compatível com MySQL, que garante alta disponibilidade e consistência. Também é possível usar um único nó, se alta disponibilidade não for necessária, por exemplo, para um banco de dados de desenvolvimento.
Os usuários do Kubernetes podem ser divididos em dois grupos. Alguns usam diretamente os Operators do Kubernetes — principalmente usuários avançados que compreendem bem como a tecnologia funciona. Outros executam isso no backend — esses usuários estão interessados em algo como Database as a Service e não querem se aprofundar nos detalhes de como o Kubernetes opera. Para o segundo grupo, temos outra solução de código aberto — Percona DBaaS CLI Tool. Esta é uma solução experimental para quem deseja obter um DBaaS de código aberto baseado em Kubernetes sem um entendimento profundo da tecnologia.
Como iniciar o DBaaS da Percona no Google Kubernetes Engine.
O Google Kubernetes Engine, na minha opinião, é uma das implementações mais funcionais da tecnologia Kubernetes. Está disponível em muitas regiões do mundo e possui uma ferramenta de linha de comando (SDK) simples e conveniente, permitindo a criação de scripts em vez de gerenciar a plataforma manualmente.
Para que nosso DBaaS funcione, são necessários os seguintes componentes:
- Kubectl.
- Google Cloud SDK.
- Percona DBaaS CLI.
Instalando o kubectl
Instalamos o pacote para seu sistema operacional, usaremos o Ubuntu como exemplo. Mais detalhes .
sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubectl
Instalando o Google Cloud SDK
Da mesma forma, instalamos o pacote de software. Mais detalhes .
# Add the Cloud SDK distribution URI as a package source
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg]
http://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
# Import the Google Cloud Platform public key
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -
# Update the package list and install the Cloud SDK
sudo apt-get update && sudo apt-get install google-cloud-sdk
Instalando Percona DBaaS CLI
Instalamos a partir dos repositórios Percona. O Percona DBaaS CLI Tool é um produto ainda experimental, portanto está disponível em um repositório experimental que deve ser ativado separadamente, mesmo que você já tenha os repositórios Percona instalados.
Saiba mais .
Algoritmo de instalação:
- Configure os repositórios Percona usando a ferramenta percona-release. Primeiro, você precisa baixar e instalar o pacote oficial percona-release da Percona:
wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb sudo dpkg -i percona-release_latest.generic_all.deb - Ative o componente experimental do repositório de ferramentas da seguinte forma:
sudo percona-release enable tools experimental - Instale o pacote percona-dbaas-cli:
sudo apt-get update sudo apt-get install percona-dbaas-cli
Configurando o funcionamento dos componentes
Mais sobre as configurações .
Primeiro, você precisa fazer login na sua conta do Google. Em seguida, o Google Cloud permite que um usuário tenha muitos projetos independentes, por isso é necessário especificar o projeto de trabalho, utilizando o código deste projeto:
gcloud auth login
gcloud config set project hidden-brace-236921
Agora vamos criar um cluster. Para demonstração, criei um cluster Kubernetes com apenas três nós — esse é o mínimo necessário para alta disponibilidade:
gcloud container clusters create --zone us-central1-a seu-nome-do-cluster --cluster-version 1.15 --num-nodes=3
O próximo comando kubectl dá as permissões necessárias ao nosso usuário atual:
kubectl create clusterrolebinding cluster-admin-binding-$USER
--clusterrole=cluster-admin --user=$(gcloud config get-value core/account)Em seguida, criamos um namespace e o tornamos ativo. Um namespace é, grosso modo, semelhante a um projeto ou ambiente, mas já dentro do cluster Kubernetes. Ele é independente dos projetos do Google Cloud:
kubectl create namespace my-namespace
kubectl config set-context --current --namespace=my-namespace
Iniciando o cluster
Depois de seguir esses passos, podemos iniciar o cluster de três nós com este simples comando:
# percona-dbaas mysql create-db example
Starting ......................................... [done]
Database started successfully, connection details are below:
Provider: k8s
Engine: pxc
Resource Name: example
Resource Endpoint: example-proxysql.my-namespace.pxc.svc.local
Port: 3306
User: root
Pass: Nt9YZquajW7nfVXTTrP
Status: ready
Como se conectar ao cluster
Por padrão, ele está disponível apenas dentro do Kubernetes. Ou seja, a partir do servidor em que você executou o comando 'Criar', não está acessível. Para torná-lo disponível, por exemplo, para testes com o cliente, é necessário redirecionar a porta através do Mapeamento de Porta:
kubectl port-forward svc/example-proxysql 3306:3306 $Depois, conecte seu cliente MySQL:
mysql -h 127.0.0.1 -P 3306 -uroot -pNt9YZquajW7nfVXTTrP
Comandos avançados de gerenciamento de cluster
Banco de dados em um IP público
Se você deseja uma solução mais permanente para a disponibilidade do cluster, pode obter um endereço IP externo. Nesse caso, o banco de dados estará acessível de qualquer lugar. Isso é menos seguro, mas muitas vezes mais conveniente. Para um IP externo, usamos o seguinte comando:
# percona-dbaas mysql create-db exposed
--options="proxysql.serviceType=LoadBalancer"
Starting ......................................... [done]
Database started successfully, connection details are below:
Provider: k8s
Engine: pxc
Resource Name: exposed
Resource Endpoint: 104.154.133.197
Port: 3306
User: root
Pass: k0QVxTr8EVfgyCLYse
Status: ready
To access database please run the following command:
mysql -h 104.154.133.197 -P 3306 -uroot -pk0QVxTr8EVfgyCLYse
Definindo explicitamente a senha
Em vez de a sistema gerar a senha aleatoriamente, você pode definir a senha explicitamente:
# percona-dbaas mysql create-db withpw --password=mypassword
Starting ......................................... [done]
Database started successfully, connection details are below:
Provider: k8s
Engine: pxc
Resource Name: withpw
Resource Endpoint: withpw-proxysql.my-namespace.pxc.svc.local
Port: 3306
User: root
Pass: mypassword
Status: ready
Eu estou mostrando a saída dos scripts em um formato legível, mas também é suportado o formato JSON.
Desligando a alta disponibilidade
O próximo comando desliga a alta disponibilidade para implantar um nó único:
# percona-dbaas mysql create-db singlenode
--options="proxysql.enabled=false, allowUnsafeConfigurations=true,pxc.size=1"
Starting ......................................... [done]
Database started successfully, connection details are below:
Provider: k8s
Engine: pxc
Resource Name: singlenode
Resource Endpoint: singlenode-pxc.my-namespace.pxc.svc.local
Port: 3306
User: root
Pass: 22VqFD96mvRnmPMGg
Status: ready
Esta é uma solução para tarefas de teste, para levantar rapidamente e facilmente o MySQL, testar e depois encerrar ou usar para desenvolvimento.
A ferramenta Percona DBaaS CLI ajuda a obter uma solução em Kubernetes semelhante ao DBaaS. Enquanto isso, continuamos a trabalhar em sua funcionalidade e usabilidade.
Esta apresentação foi feita pela primeira vez na por Mail.ru Cloud Solutions & Tarantool. Veja outras apresentações e inscreva-se para receber atualizações de eventos no Telegram .
O que mais ler sobre o tema:
Fonte: habr.com
