O Google Cloud SQL autoriza grupos de instâncias da escala automática

4

Eu tenho um grupo de instâncias configurado com o Auto Scaling e o Load Balancing. Também estou usando o Google Cloud SQL para o servidor MySQL.

Sempre que o grupo de instâncias for dimensionado e adicionar outra instância, a instância receberá um novo endereço IP. O problema é que essa instância não tem mais acesso à instância do Google SQL (já que a instância do SQL exige que as redes autorizadas sejam pré-configuradas). O que posso fazer sobre isso?

Atualmente, estou aceitando a maioria dos IPs para o meu servidor SQL, adicionando os seguintes IPs aos IPs autorizados no gerenciador de SQL: 100.0.0.0/6 104.0.0.0/5 112.0.0.0/4

    
por Dean 25.05.2016 / 02:14

3 respostas

5

Como já foi mencionado por @justbeez, acredito que o melhor caminho a seguir é usar instâncias de segunda geração e Cloud SQL Proxy . Caso isso não seja possível, instâncias de primeira geração podem ser configuradas para permitir somente conexões SSL e colocar na lista de permissões qualquer origem, conforme explicado aqui .

Uma abordagem mais complexa seria criar um modelo para que um startup-script é executado no momento da inicialização e autoriza o endereço IP da instância por gcloud . O IP pode ser removido da mesma forma no horário de encerramento .

O endereço IP da VM do GCE pode ser obtido no servidor de metadados

curl "http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip" -H "Metadata-Flavor: Google" 
    
por 05.12.2016 / 19:17
1

Se você estiver usando uma instância do Second Generation Cloud SQL, convém usar o método de conexão do Cloud SQL Proxy: link

Em resumo, você instala o proxy do Cloud SQL localmente em suas instâncias e se autentica por meio de uma conta de serviço. Em seguida, você se conecta a ele da mesma forma como se conectaria usando um soquete UNIX ou TCP.

Isso requer um pouco de configuração, mas não requer nenhuma lista de permissões de IP. Depois de configurá-lo, basta adicionar essa versão a qualquer modelo de escala automática que você esteja usando.

Observação: se você estiver usando contêineres do Docker, eles têm uma versão do Cloud SQL Proxy envolta em uma imagem do Docker que você pode adicionar aos seus pods como um serviço: link

(A única outra opção que consigo pensar é usar a API para editar a lista de permissões em resposta aos eventos de escalonamento automático.)

    
por 13.07.2016 / 01:05
0

Ok, eu não postei muito, mas esse problema me custou uma perda de tempo e esforço. Espero que esta informação ajude as pessoas que enfrentam o mesmo problema:

Usar o Cloud SQL Proxy parece ser a maneira como o GCP está pressionando todos para superar esse obstáculo. No entanto, lembre-se de que, depois de percorrer esse caminho, você será acoplado ao GCP. Seu aplicativo precisará ter conhecimento direto de um componente específico do GCP para poder se comunicar com o banco de dados - algo que é necessário apenas para o aplicativo ser executado no GCP e em nenhum outro lugar.

Devido a essa consequência indesejável, optei por seguir a abordagem "mais complicada" do @ Carlos. A vantagem dessa abordagem é que ela isola a lógica necessária para se comunicar com a instância do SQL e a associa a configurações específicas do GCP, em vez do próprio aplicativo.

O código a seguir é o script de inicialização que escrevi para permitir que um modelo de instância de inicialização automática obtenha autorização para uma instância do SQL. Ele é executado dentro do Container-Optimized OS do GCP, que não possui o gcloud instalado.

#!/bin/bash
PROJECT=<your project>
DB=<your db name>

METADATA=http://metadata.google.internal/computeMetadata/v1

# Get the external IP of this instance
EXTERNAL_IP=$(curl -s "$METADATA/instance/network-interfaces/0/access-configs/0/external-ip" -H "Metadata-Flavor: Google")

# Get access to call the SQL API
curl -s --header "Authorization: Bearer $ACCESS_TOKEN" -X GET https://www.googleapis.com/sql/v1beta4/projects/$PROJECT/instances/$DB?fields=settings/ipConfiguration/authorizedNetworks/value | grep value | awk -F\" '{print $4}' && \
SVC_ACCT=$METADATA/instance/service-accounts/default && \
ACCESS_TOKEN=$(curl -H 'Metadata-Flavor: Google' $SVC_ACCT/token | cut -d'"' -f 4)

# Get the IPs that are authorized to the database
EXISTING_IPS=$(curl -s --header "Authorization: Bearer $ACCESS_TOKEN" -X GET https://www.googleapis.com/sql/v1beta4/projects/$PROJECT/instances/$DB?fields=settings/ipConfiguration/authorizedNetworks/value | grep -B1 -A1 value | tr -d '\n')

# If the $EXTERNAL_IP is already authorized, then there's nothing to do
[ -n "$(echo $EXISTING_IPS | grep $EXTERNAL_IP)" ] && exit 0

# If the $EXISTING_IPS is not empty, prepend a comma
[ -n "$EXISTING_IPS" ] && EXISTING_IPS=", $EXISTING_IPS"

# Patch the database settings with the new authorized IPs
curl -s --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data "{\"settings\":{\"ipConfiguration\":{\"authorizedNetworks\":[{\"value\":\"$EXTERNAL_IP\"}$EXISTING_IPS]}}}" \
     -X PATCH \
     https://www.googleapis.com/sql/v1beta4/projects/$PROJECT/instances/$DB

# Dump the database settings for visual verification
curl -s --header "Authorization: Bearer $ACCESS_TOKEN" -X GET https://www.googleapis.com/sql/v1beta4/projects/$PROJECT/instances/$DB?fields=settings

Atualização : esta solução está disponível em meu repositório público do GitHub .

    
por 16.03.2018 / 15:42