Cenário de locação multi core válido? [fechadas]

Question

Atualmente estou mexendo com um cenário para usar o CoreOS. Provavelmente não é o caso de uso de primeira classe. Mas eu gostaria de obter um ponteiro se é válido embora. Como estou realmente no começo de obter o CoreOS, espero que meu "caso de uso" não esteja totalmente errado.

Imagine um aplicativo multilocatário no qual cada locatário deve obter seu próprio ambiente de tempo de execução. Vamos usar um aplicativo da web em execução no Node.js e no PostgreSQL para armazenamento de dados, conforme fornecido. Cada ambiente de locatário seria executado no CoreOS em seus respectivos contêineres. A persistência de dados é deixada de fora por enquanto. Para mim, atualmente é mais sobre a viabilidade geral.

Então, por que o CoreOS?

Atualmente, tento manter a ideia de ambientes separados por locatário. Para otimizar a densidade de instâncias de servidor de banco de dados e de hospedagem por host de hardware, achei que o CoreOS poderia ser a escolha certa em vez da virtualização "clássica".

Outra razão é que muitos inquilinos podem não precisar de mais do que uma única instância de banco de dados pequena e um único servidor da Web pequeno. Mas pode haver outros inquilinos que precisam de implementações constantemente dimensionadas. Outros podem precisar de uma escala temporária durante os horários de pico. CoreOS soa como um bom ajuste aqui também.

No outro lado, deve haver uma infra-estrutura de mensagens escalável (RabbitMQ) atrás que manipule muitas mensagens. Essa infra-estrutura será usada por todos os locatários e precisa ser dimensionada dinamicamente na melhor das hipóteses. Provavelmente, haverá também uma infra-estrutura Elasticsearch "a ser dimensionada". Visto através do meu "CoreOS para todos os óculos", este parece ser um bom ajuste também.

No caso de todo esse cenário ser geralmente válido, atualmente não consigo ver como seria possível rotear o tráfego de um site geral disponível para os diferentes contêineres de inquilino.

Imagine que o aplicativo está sendo executado em app.greatthing.tld. Um usuário pode entrar e deve ser apresentado o aplicativo servido para o inquilino. Isso é algo que o socketplane e / ou a flanela estão lá para resolver? Ou como seria uma solução para obter o inquilino servido pelos contêineres certos? Eu acho que é uma questão geral. Mas, pelo menos no contexto de um ambiente containerizado do CoreOS, não consigo ver como lidar com isso.

    

Answer 1

Parece que seu principal problema é o roteamento. Você precisaria configurar algum tipo de camada de roteamento que é o ponto de entrada no cluster, lê o cabeçalho do host e encaminha o tráfego para o (s) recipiente (s) apropriado (s). Uma maneira comum de fazer isso é confd + nginx rodando em um container.

A segunda parte disso é ter seus contêineres de back-end "anunciando" eles mesmos, ou seja, escrever alguns dados no etcd quando eles estiverem ativos e tiverem passado por suas verificações de saúde. Isso permite que você se mova pelos back-ends à medida que você implanta novas versões, escala, etc.

Então, como você implanta isso? Primeiro, confira as arquiteturas de cluster doc. Eu pegaria um subconjunto de suas máquinas e as colocaria atrás de um LB de nuvem (ou rodaria o DNS robin) que aponta para seus contêineres de roteamento rodando em 80/443. Estes, então, encaminham o infra-cluster de tráfego para o backend apropriado.

Não há necessidade de usar flanela ou outros projetos de rede se você estiver apenas armazenando a combinação IP / porta do back-end para se conectar.