Persistindo dados -BTSync

Olá,

Hoje o mundodocker.com.br dará inicio a uma série de posts que tem por objetivo trazer soluções práticas para a persistência de dados no ambiente Docker.

Uma das premissas de se utilizar Docker é de que seu container é descartável, sim, isso pode parecer um tanto quanto radical, mas container em si foi desenvolvido para atender um processo durante um tempo determinado, e não para servir como um servidor virtual, nesse sentido, um cuidado que se deve ter é persistir os dados importantes de sua aplicação em um volume, ou até mesmo em um sistema de arquivo distribuído, dessa forma um container pode morrer, sem que sua aplicação morra junto.

Vamos ver nessa série, algumas alternativas para isso, e começamos com a mais simples delas: BTSync. Para quem não conhece o BTSync é uma ferramenta que utiliza o protocolo do Bittorrent para sincronismo de dados, através dele é possível sincronizar pastas e arquivos entre diferentes plataformas (desde que tenha o Sync instalado), de forma segura e rápida. No nosso exemplo vamos simular a sincronização de dados entre containers, dessa forma você pode fazer com que diversos containers tenha os dados de sua aplicação, garantindo assim maior disponibilidade. Mãos a obra então:

Como vocês já sabem, vamos criar um Dockerfile para gerarmos uma imagem e carrega-la para onde quisermos, esse é um bom exemplo:

FROM ubuntu:14.04

RUN apt-get update && apt-get install -y curl
RUN curl -o /usr/bin/btsync.tar.gz http://download-lb.utorrent.com/endpoint/btsync/os/linux-x64/track/stable; cd /usr/bin && tar -xzvf btsync.tar.gz && rm btsync.tar.gz
RUN mkdir -p /btsync/.sync; mkdir -p /var/run/btsync; mkdir -p /data

EXPOSE 8888
EXPOSE 55555

ADD start.sh /usr/bin/start.sh

RUN chmod +x /usr/bin/start.sh

VOLUME ["/data"]

ENTRYPOINT ["start.sh"]

 

Na mesma pasta onde está esse Dockerfile, crie um arquivo chamado: start.sh com o seguinte código:

#!/bin/bash
SECRET="${@}"
: ${SECRET:=`btsync --generate-secret`}

echo "Starting btsync with secret: $SECRET"

echo "{
 \"device_name\": \"Sync Server\",
 \"listening_port\": 55555,
 \"storage_path\": \"/btsync/.sync\",
 \"pid_file\": \"/var/run/btsync/btsync.pid\",
 \"check_for_updates\": false,
 \"use_upnp\": false,
 \"download_limit\": 0,
 \"upload_limit\": 0,
 \"shared_folders\": [
 {
 \"secret\": \"$SECRET\",
 \"dir\": \"/data\",
 \"use_relay_server\": true,
 \"use_tracker\": true,
 \"use_dht\": false,
 \"search_lan\": true,
 \"use_sync_trash\": false
 }
 ]
}" > /btsync/btsync.conf

btsync --config /btsync/btsync.conf --nodaemon

Explicando: Você pode definir, via arquivo de configuração, algumas variáveis para o btsync trabalhar, como por exemplo chave para estabelecer comunicação, diretório que será sincronizado e limites de transferência, é claro que em nosso teste não vamos definir algumas delas, apenas alterei o “dir” para que seja sincronizado o diretório /data, você pode definir qualquer um. Por padrão, a porta de comunicação é a 55555, você pode modificá-la sem problema, e não é necessário você mapear portas do host para o container ;).

Então, criado o Dockerfile e o start.sh, vamos gerar a imagem:

docker build -t bt_mundodocker .

Agora é simples, basta você iniciar o primeiro container:

docker run -d --name repl1 bt_mundodocker

Você deve capturar a chave gerada na inicialização desse container, ela será útil para quando você iniciar o segundo container, pois será a chave que permitirá estabilizar a conexão entre os peers do btsync:

docker logs repl1

A saída desse comando, será algo parecido com isso:

Starting btsync with secret: ANDHOU5F7NHNR3EBPFYBPFJJMKATGLBEK
[20160329 21:23:04.194] total physical memory 536870912 max disk cache 2097152
[20160329 21:23:04.195] My PeerID: 102D9BFD720DF686F77DD0BC7FE5FDC98C767930
[20160329 21:23:04.683] LC: license expired
[20160329 21:23:05.291] LC: license renewal

Basta você inicializar o segundo container, passando essa chave como parâmetro:

docker run -d --name repl2 bt_mundodocker ANDHOU5F7NHNR3EBPFYBPFJJMKATGLBEK

Veja agora o retorno do comando docker logs desse container:

Starting btsync with secret: ANDHOU5F7NHNR3EBPFYBPFJJMKATGLBEK
[20160329 21:27:07.480] total physical memory 536870912 max disk cache 2097152
[20160329 21:27:07.482] My PeerID: 1015FC44C961E6AB9B77AD3951437CC69C6D357A
[20160329 21:27:07.756] LC: license expired
[20160329 21:27:08.084] LC: license renewal
[20160329 21:27:08.090] PeerConnection[0x00007fe9bc001170] incoming connection from 172.17.0.42:57871
[20160329 21:27:08.143] PeerConnection[0x00007fe9bc001170] incoming connection from 172.17.0.42:57871
[20160329 21:27:09.260] PeerConnection[0x00007fe9bc20a1c0] incoming connection from 172.17.0.42:55555

Para testar, acesse os containers (docker exec -it repl1/repl2 /bin/bash), crie arquivos dentro da pasta /data e veja que eles serão sincronizados entre os containers, mesmo se você tiver mais de dois containers. Legal né? Todo o trafego entre os containers (mesmo os que não sejam locais) é criptografado, e apenas peers (containers) que iniciaram com a chave mencionada é que entram na replicação. Claro, nem tudo são flores, quanto maior a latência entre os containers, mais lento será essa replicação, então pense bem antes de sair utilizando ele para qualquer coisa 🙂

Fácil, simples e muito eficiente, essa foi a apresentação da primeira solução para persistência de dados entre os containers, fique atento aos próximos. Se gostou, ajude divulgando o Blog.

Grande Abraço!

Caso de Sucesso – GoodBye.Host

Oi Pessoal,

Hoje queremos trazer para você um exemplo prático de Docker em produção, e como ele pode ser útil quando você trabalha de forma correta com micro-serviços.

Há 6 meses atrás, quando o pessoal do https://goodbye.host lançou a V1 da plataforma de migração, tinham em mente apenas uma coisa: Fazer mudanças de forma fácil, e isso inclui  mudanças de arquitetura/código/tecnologia e no processo de migração de sites, e-mail e banco de dados, tornado-o mais fácil, rápido e seguro.

Tendo isso em mente, a opção mais lógica na época (e hoje prova-se como sendo a melhor e mais acertada) era projetar a plataforma para trabalhar com micro-serviços, de forma independente e modular, garantindo assim maior segurança  e eficiência na ferramenta. Mas afinal, por que mudar?

A primeira versão da plataforma foi projetada para trabalhar utilizando servidores (físico ou virtuais), de forma uma pouco engessada, tornando difícil o scale da aplicação e manutenção do ambiente como um todo, pois as modificações eram complexas e em alguns casos demoradas, para Cassio Bock, desenvolvedor da plataforma, era necessário tornar esse ambiente mais eficiente, autonomizável e simples. Depois de uma série de pesquisas, testes e conversas, o Docker se sobressaiu frente as outras alternativas. Veja abaixo uma imagem de como era o ambiente antes:

goodbye-antes

Antes, para cada processo de migração, havia um fluxo sequencial, que garantia a execução de cada migração. Dessa forma, criava-se uma fila de processamento, que em alguns casos atrasava as tarefas de outros usuários. O ambiente era dessa forma devido a dois fatores:

1 – As tecnologias utilizadas, em algumas das camadas, eram monolíticas, tendo que adaptar outras partes da plataforma para atender uma necessidade não suprida pelas demais.

2 – Necessidade de controle manual em cima de tarefas que poderiam ser auto-gerenciadas.

Depois de alguns desenhos, a arquitetura ideal encontrada foi essa:

goodbye-depois

Na nova arquitetura, quando uma migração é criada, um container é iniciado, isso feito tudo através da API do Swarm, sendo muito mais fácil adaptar a plataforma as necessidades que aparecerem. Outro ponto positivo nesse ambiente é  fato de as camadas serem independentes, então o site ou api não precisam ficar aguardando um retorno para seguirem com as tarefas, isso torna a plataforma escalável e claro, muito mais ágil.

Através do Swarm foi possível criar um cluster para a execução dos containers, então, quando uma migração é iniciada, não é necessário saber onde ela será realizada (passo que era necessário na arquitetura anterior), basta criar o container via API do próprio Swarm, e ele mesmo provisionará o container no melhor nó possível. Outra tecnologia utilizada é o Socket.io, responsável pelo acompanhamento da migração, com ele foi possível desenvolver um método onde o container que está realizando a migração, informe ao cliente sobre o andamento da mesma, dessa forma têm-se a certeza de que a migração está sendo realizada, e em que etapa ela encontra-se.

Por hoje era isso, quer saber mais ou conversar sobre como foi o processo de mudança? Mande e-mail para nós e vamos conversando. Gostou? Então nos ajude divulgando o Blog 😉

Abraço!

Docker e .Net

Oi pessoal!

Rodar .Net em container? SIM!! é possível, e vamos mostrar hoje como você pode fazer esse ambiente funcionar e testar sua aplicação. Bem, antes de tudo você precisa entender todo o movimento que a Microsoft vem fazendo para que sua linguagem de programação torne-se cada vez mais utilizada pelos desenvolvedores, para isso eles repensaram tudo que já fizeram, e lançaram uma versão do .Net com features muito parecidas como as encontradas em node e ruby on rails, e a batizaram de ASP.NET Core. Conceitualmente o ASP.NET Core é uma plataforma open source de desenvolvimento leve e eficiente para aplicação escritas em .net, veja abaixo uma lista dos principais pontos do asp.net Core:

  • Suporte integrado para criação e utilização de pacotes NuGet;
  • Pipeline de request mais leve e modular;
  • Ambiente configurado para cloud;
  • Suporte a injeção de dependência;
  • Novas ferramentas que facilitam o desenvolvimento web;
  • Capacidade de hospedar o processo no IIS ou em um Self-Host;
  • Suporte para desenvolvimento de aplicação asp.net em Windows, Linux e Mac;
  • Open Source e com comunidade ativa;
  • Todos os pacotes do .Net no NuGet;
  • .Net Core construido com suporte a versionamento side-by-side;
  • Uma unica Stack para Web UI e Web APIs;

Por que a Microsoft vem tomando esse rumo? Simples, para atrair mais pessoas para o seu produto, tendo em vista que as principais linguagens, ou as que mais crescem tem nativas todas essas features, a melhor alternativa para a Microsoft foi mudar a abordagem e atrair pessoas para melhorar seu produto/serviço e claro, isso consolida ainda mais o Windows Azure, fazendo com o desenvolvimento e deploy de Apps em .net torne-se menos doloroso.

Vamos ver isso rodando em um container?

Simples, tendo o Docker instalado (em qualquer host, seja ele Windows, Linux ou Mac), execute:

docker run -it microsoft/dotnet:latest

Dentro do container, você deve criar sua aplicação, de forma parecida com o que ocorre com o ruby on rails, para isso o .net core disponibiliza um utilitário chamado: dotnet, veja:

mkdir app
cd app
dotnet new

O comando dotnet new criará toda a estrutura necessária para rodar uma aplicação hello world básica, ele criará um arquivo chamado project.json com o seguinte código:

{
 "version": "1.0.0-*",
 "compilationOptions": {
 "emitEntryPoint": true
 },
 "dependencies": {
 "Microsoft.NETCore.Runtime": "1.0.1-beta-*",
 "System.IO": "4.0.11-beta-*",
 "System.Console": "4.0.0-beta-*",
 "System.Runtime": "4.0.21-beta-*"
 },
 "frameworks": {
 "dnxcore50": { }
 }
}

Esse arquivo project.json contém as informações de dependência que sua aplicação precisará para rodar, é fundamental que você informe nesse aquivo todos os pacotes que necessita. Nessa mesma estrutura será criado um arquivo chamado Program.cs com este código:

using System;
namespace ConsoleApplication
{
 public class Program
 {
 public static void Main(string[] args)
 {
 Console.WriteLine("Hello World!");
 }
 }
}

Agora basta realizar a instalação das dependências:

dotnet restore

E pronto, sua aplicação estará pronta para rodar, basta executar o comando:

dotnet run

 Fácil certo? E é possível deixar ainda mais fácil, para isso, basta criar Dockerfile e gerar uma imagem com esse ambiente:

FROM microsoft/dotnet:latest
RUN mkdir /app
WORKDIR /app
RUN ["dotnet", "new"]
RUN ["dotnet", "restore"] 
ENTRYPOINT ["dotnet", "run"]

Agora crie a imagem: docker build -t myapp .

E crie um container baseado nessa nova imagem: docker run -d myapp , quer ver o que retornou nessa execução? docker logs iddocontainer, ele deverá retornar algo desse tipo: Hello World!.

É claro que você pode aprimorar esse ambiente, principalmente se quiser rodar uma aplicação web, mas esse ambiente básico já serve como inicio para seus testes ;).

Gostou? Então nos ajude divulgando o mundodocker.com.br, grande abraço!

Supervisord – Gerenciando serviços

Eai gente, tudo tranquilo?

O LXC propriamente dito não foi desenvolvido para ter múltiplos serviços/processos em cada container, o ideal é que você segmente seu ambiente em diversos containers, cada um rodando um parte isoladamente. Mas Cristiano, eu realmente preciso ter 2, 3 serviços em um mesmo container, o que faço? Bom, se não tem jeito mesmo, você pode utilizar o supervisord para gerenciar seus processos dentro de um container, e garantir que eles iniciem juntamente com o container.

O supervisord para quem não conhece é um utilitário que serve para monitorar e reiniciar os serviços nele definidos quando esses serviços entram em um estado de falha, ele é escrito em python e é muito simples de se utilizar, ele possuí 2 comandos básicos:

  • supervisord: É o deamon propriamente dito, responsável por ler o arquivo de configuração e monitorar os serviços definidos;
  • supervisorctl: É um subutilitário que serve para poder reiniciar manualmente o serviço ou ainda verificar qual o status do serviço para o supervisord;

Vou mostrar como você pode utilizar o supervisord já com o container rodando, mas como você já viu nesse post, você pode converter todos esses comandos em um Dockerfile e dar um docker build e gerar um imagem pronta ;). Vamos lá:

1 – Instalando

c45cffcd9126:~# yum install python-setuptools -y
c45cffcd9126:~# easy_install pip
c45cffcd9126:~# pip install supervisor

2 – Configurando

c45cffcd9126:~# echo_supervisord_conf > supervisord.conf
c45cffcd9126:~# cp supervisord.conf /etc/supervisord.conf
c45cffcd9126:~# vi /etc/supervisord.conf

Agora basta você adicionar o bloco de comandos referente ao(s) serviço(s) que precisamos que sejam iniciados com o container, como por exemplo o ssh e o apache como definido abaixo:

[supervisord] 
nodaemon=false

[program:sshd] 
command=/usr/sbin/sshd -D 

[program:apache] 
command=/usr/sbin/httpd -DFOREGROUND -k start

Ah claro, não esquece de instalar esses serviços 😉

c45cffcd9126:~# yum install openssh-server httpd -y

Agora está no fim, crie um arquivo no / com nome de run.sh com o seguinte conteúdo

#!/bin/bash
/usr/bin/supervisord -c /etc/supervisord.conf
/bin/bash

Não esqueça da permissão de execução: chmod +x /run.sh

E está pronto o seu container, com o supervisord monitorando e mantendo no ar os serviços definidos, quer testar? Inicie o daemon: /usr/bin/supervisord -c /etc/supervisod.conf e verifique se os serviços que você definiu estão com status de running, para isso utilize:

c45cffcd9126:~# supervisorctl
apache RUNNING pid 160, uptime 0:00:03
sshd RUNNING pid 161, uptime 0:00:03
supervisor>

O supervisorctl possuir vários recursos, veja como você pode consultar:

supervisor> ?
default commands (type help <topic>):
=====================================
add exit open reload restart start tail
avail fg pid remove shutdown status update
clear maintail quit reread signal stop version
supervisor>

Através dele você pode parar, iniciar, atualizar entre muitas outras opções. Agora basta você gerar um imagem desse container:

docker commit containerid nomedaimagem

Feito isso você terá gerado a imagem do container, agora basta iniciar um novo container baseado nessa imagem:

docker run -d -p 80:80 -p 22:22 nomedaimagem /run.sh

E pronto, você terá iniciado 2 serviços diferentes dentro do mesmo container, e o melhor, eles reiniciarão sozinhos quando entrarem em failed state, legal não?

Espero ter ajudado, e já sabe, tendo dúvida entre em contato conosco ou deixe sua dúvida no fórum que o pessoal pode te ajudar :), quer nos ajudar? Divulgue o mundodocker.com.br e vamos conversando.

Abraço!

:

Docker 1.10

Oi Pessoal,

Novidades no Docker, é claro que tem aqui no  mundodocker.com.br ;). Vamos trazer um apanhado do que há de novo na última versão da engine, assim como nas ferramentas do seu ecossistema. Vamos lá:

Docker Engine 1.10

  • Melhoramento na captura de eventos: A instrução docker events foi reformulada e teve uma melhoria significativa nos métodos utilizados, isso garante um tempo de resposta menor e mais precisão nos dados capturados.
  • Aperfeiçoamento no trabalho com imagens: Foram refatorados diversos trechos de código o que tornou o download e upload de imagens cerca de 3 vezes mais rápida, e garante um melhor controle em caso de falha do download.
  • Alteração de configuração online: Quando você seta os valores de limite (como cpu, memória, etc), tradicionalmente você precisaria reiniciar o container ou até mesmo recria-lo, agora na versão 1.10 você pode fazer essa alteração online, utilizando o comando: docker update.
  • Arquivo de configuração: Agora é possível redefinir alguns parâmetros e recarregar o docker sem a necessidade de reiniciar nada.
  • Sistema de arquivo temporário: A partir da versão 1.10 ficou mais fácil criar um ponto de montagem temporário, isso é muito útil quando você tem um container read-only mas sua aplicação precisa escrever em disco (log, sessão, etc), basta passar o parâmetro: –tmpfs no docker run.
  • Restrições de I/O de disco: É possível definir diversos parâmetros para restringir acesso a disco, entre eles: --device-read-bps, --device-write-bps, --device-read-iops, --device-write-iops, e --blkio-weight-device
  • Novo plugin de log: Agora é possível integrar o Splunk ao Docker para coleta dos logs.
  • Entre outras diversas correções de segurança e performance.

Docker Swarm 1.1

  • Reagendar containers quando um nó falhar: Essa é uma solução em fase de testes ainda, mas permite que o Swarm recrie o container em um nó que esteja disponível para atender, lembrando que esse é um recurso de teste, é possível que tenha alguns bug ainda.
  • Foram realizadas diversas melhorias para definição da ‘saúde’ do nó, isso garante um melhor gerenciamento dos recursos utilizados e claro possibilita criar um politica mais eficiente de deploy.

Docker Network

Na parte de rede do Docker foram feitas algumas melhorias significativas, algumas apenas ajustes e resolução de problemas encontrados na versão anterior, outras novidades mesmo, entre elas:

  • Rede Interna: Agora é possível criar uma rede para trafego interno (de entrada e saída), facilitando assim a sub-divisão das redes e facilita a organização topológica de seus ambiente.
  • IP personalizado: Você pode definir um ip personalizado independente da rede onde ele está criado, você não fica restrito ao range de ip de onde sua rede pertence.
  • Rede multi-host: Suporte todas as versões antigas do kernel (do 3.10 em diante), até a versão 1.9 você só poderia utilizar esse recursos em uma versão especifica do kernel.

Docker Compose, Machine e Registry: Tiveram algumas correções de bug e refatoração em seus códigos para que ficassem mais performáticos, mas nenhuma grande novidade, mas com certeza serão trabalhados para a próxima versão.

Espero que tenha ajudado, e não fique esperando, baixe e utilize essa última versão, para a comunidade isso é muito importante, quanto mais feedback melhor, e isso vale para o nosso blog também 😉

Se gostou, ajuda divulgando o blog, grande abraço!

Docker – API Autenticada

Oi Pessoal,

Uma das grandes vantagens em se utilizar o Docker em vez de LXC puro é a facilidade de se trabalhar utilizando uma API de integração, isso facilita e agiliza a vida tanto de programadores quanto do pessoal de operações. Alguns cuidados devem ser tomados é claro, entre eles em não expor a API de seu host Docker, pois nativamente não há um método de limitar o acesso. Existem soluções para isso? É claro, e hoje o mundodocker.com.br abordará um delas: Docker API com Basic Authentication.

Passo 1:

Primeiramente você deve expor a API do Docker apenas localhost, para isso você deverá editar o arquivo de configuração, no nosso exemplo (CentOS 7) é no /etc/sysconfig/docker, e deixe-o assim:

OPTIONS='-H tcp://127.0.0.1:2376 -H unix:///var/run/docker.sock'

Em seguida reinicie o serviço do Docker:

systemctl restart docker.service

Passo 2:

Agora precisamos instalar e configurar um proxy http (Nginx, Apache, etc), no nosso exemplo vamos utilizar o Nginx, para isso:

yum install nginx -y

Agora precisamos definir as credenciais de acesso, é simples, basta criar .htpasswd e fazer com que o proxy exija usuário e senha em uma determinada url, vamos lá:

htpasswd -c /etc/nginx/.htpasswd USUARIO

Ele solicitará a senha, digite-a duas vezes e está pronto seu arquivo de autenticação.

Agora vamos a configuração do proxy, para isso precisamos editar o arquivo: /etc/nginx/conf.d/default.conf e deixe-o da seguinte forma:

server {
 listen 2375 default_server;
 server_name localhost;
 location / {
 proxy_pass http://127.0.0.1:2376;
 auth_basic_user_file /etc/nginx/.htpasswd;
 auth_basic "Acesso restrito a API do Docker";
 }
}

O que falta? reiniciar o serviço do Nginx:

systemctl restart nginx.service

Testes

Depois de tudo configurado (se fosse não encontrar nenhum erro no caminho também 😉 ) basta você testar de uma forma bem simples: http://ipdoservidor:2375/info ele solicitará os dados informados anteriormente via htpasswd e retornará algumas informações do Docker e dos containers que está em execução neste host.

Você pode optar por outro método, que é o certificado SSL diretamente na API do Docker, isso garante que apenas clientes confiáveis tenham acesso ao host (pois deverão tem o certificado client configurado). E claro, você pode configurar para que o Nginx trabalhe sob SSL, isso garante que, além da autenticação com usuário e senha, você ainda tenha todos os seus dados trafegados de forma criptografada (esse sim é um ótimo método).

Por hoje era isso gente, gostaram? Ajudem divulgando o Blog por ai 😉

Abraços!

Docker Universal Control Plane – Parte 1

Oi Pessoal,

Depois de um tempo nas postagens, hoje vamos iniciar os trabalhos aqui no https://www.mundodocker.com.br, trazendo para vocês uma das soluções que o Docker disponibilizou (ainda em fase beta) e que veio como resultado da aquisição da Tutum, que é o Docker Universal Control Plane. Entenda um pouco mais sobre as suas funcionalidades e objetivos neste primeiro post.

O Docker UCP, assim como algumas ferramentas que já apresentamos aqui (vide Rancher) é uma alternativa de painel para administração de sua infraestrutura de Docker, seja ela local ou na nuvem, a diferença entre essas ferramentas é basicamente a empresa que presta suporte e mantem a ferramenta, no caso da UCP a própria Docker. Em questão de funcionalidades tanto Rancher quanto UCP são bem parecidas, com a diferença novamente de que a UCP é 100% compatível com o Docker e suas ferramentas nativas, como por exemplo a Docker Swarm e Compose. Veja abaixo uma listagem das funcionalidades e benefícios da Docker UCP:

Solução voltada para empresas:

Um dos recursos que existe no UCP é a opção de integrar o método de autenticação em seu LDAP ou AD, isso é muito mais seguro e claro ajuda na organização e delegação de funções dentro do painel.

Gerenciamento nativo de seu ambiente Docker:

Como mencionei acima, o Docker UCP é desenvolvido pela própria Docker, isso garante 100% de compatibilidade entre todas as ferramentas que a Docker já disponibiliza e este painel, e claro, torna mais fácil a integração entre as diferentes ferramentas.

Administração simplificada:

Você pode gerenciar desde containers individuais até aplicações mais complexas que utilizam o Docker Compose, você pode de forma fácil criar um conjunto de rede ou volume e associar a sua aplicação/container apenas via interface web, sem a necessidade de acessar os servidores.

Resultado mais rápido:

O UCP permite você gerenciar e otimizar seu deploy de aplicação, você pode configurar todo seu ambiente, incluindo repositório de imagens e servidores em poucos cliques, isso é muito mais prático do que ficar configurando o ambiente via linha de comando e claro gera retorno muito mais rápido, o que no mundo DevOps isso é imprescindível.

 Agilidade e Controle:

Crie, gerencie e faça deploy de qualquer aplicação, em qualquer lugar, quando quiser, escale, distribua e altere quando for necessário sem perder o controle, esse é um dos pontos fundamentais do UCP, e uma das vantagens mais interessantes para os times de desenvolvimento e infra estrutura.

Escalável e disponível:

O Docker UCP foi desenhado e desenvolvido para ser altamente disponível e para que você possa escalar de forma fácil e rápida, para isso ele utiliza como engine de clusterização o Docker Swarm, que como já explicado aqui no blog, é extremamente leve e fácil de se administrar. Para garantir uma maior disponibilidade o Docker UCP pode ser integrado com algum serviço de entrega de chave-valor, como Consul, Etcd, dentre outros, isso na verdade é uma das premissas para se ter o Docker UCP rodando em seu ambiente, pois apenas utilizando um desses serviços é que se garante a disponibilidade da ferramenta.

Fique atento, em breve postaremos mais alguns posts sobre essa ferramenta, e quem sabe um vídeo ;).

Gostou? Nos ajude divulgando o blog, abraço!