A AWS premiou os parceiros ao redor do mundo que mais se destacaram no ano.

A Amazon Web Services (AWS), uma empresa Amazon.com, anunciou hoje os vencedores do AWS Patrner Awards, uma premiação que reconhece os parceiros ao redor do mundo que mais se destacaram ao oferecer soluções AWS, ajudando seus clientes a proporcionarem uma verdadeira transformação digital em seus processos. 

Os prêmios foram anunciados durante o Partner Awards Gala, no AWS re:Invent. O AWS Partner Awards é uma premiação que busca premiar os parceiros AWS que adotaram em seus negócios modelos inovadores, colaborativos e especializados em nuvem no último ano, buscando sempre evoluir ao lado de seus clientes através de soluções da AWS. Dentre elas está a Darede, que conquistou o prêmio Collaboration Partner of the Year – LATAM, que destaca a capacidade da empresa de colaborar com projetos de outros parceiros AWS e assim oferecer as principais soluções da plataforma.  

  

O CEO e cofundador da Darede, Muriel Arneiro destacou o propósito da empresa. “Estamos honrados por mais esse prêmio. Na Darede buscamos todos os dias transformar a vida de pessoas e empresas através da tecnologia, por isso esse prêmio é tão significativo, pois é a certeza que estamos no caminho certo.”  

  

Exemplo de um parceiro colaborativo da Darede, é a TripleS, uma consultoria de TI, que apesar da concorrência, se uniu à Darede para oferecer uma solução AWS totalmente otimizada para uma empresa de energia, como pode ser visto nesse caso.  (https://aws.amazon.com/pt/solutions/case-studies/comerc-energia/). Marcos Ferrari, um dos fundadores da TripleS, destacou a parceria com a Darede: “A Darede é um parceiro super estratégico, e nos ajudou muito no início da nossa jornada para nuvem, e ainda ajuda. Não é comum encontrarmos empresas dispostas ajudar, compartilhando experiências com uma empresa do mesmo ramo. Com a Darede, foi diferente e certamente todos saíram ganhando, nós, eles e principalmente nossos clientes. Por isso temos o orgulho de trabalhar com a Darede e aproveito para parabenizar a todos da empresa.” 

  

Essa foi a primeira vez que o AWS Partner Awards permitiu que os próprios parceiros da plataforma se autoindicassem para as categorias do prêmio sejam elas em nível regional e global, todas empresas que integram a rede de parceiros AWS foram convidados a participarem da premiação.  

 

A Rede de parceiros AWS (APN), é um programa de parceria global, que tem como objetivo ajudar as empresas parceiras a construir negócios ou soluções de sucesso com base na AWS, fornecendo suporte comercial, técnico e de marketing.   

 

“Os parceiros AWS são nosso foco central para agregar valor a nossos clientes no mundo todo, atingindo a uma ampla variedade de setores”, afirmou Ruba Borno, Vice Presidente de Canais e Parcerias Globais da AWS.Temos a honra de apresentar o primeiro prêmio global, 2022 AWS Partner Awards, e agradecemos a todos os indicados e vencedores por acelerar a jornada de transformação para a Nuvem em nossos clientes. 

 

OUTRAS PUBLICAÇÕES

DNS e as dúvidas quando precisa hospedar uma aplicação – Parte 1

Será que agora vou saber o que estou fazendo quando crio aquela entrada TXT, ou CNAME quando sigo um procedimento? Se você está lendo esse nosso primeiro artigo, deve estar com aquela pulga atrás da orelha, aquele sentimento de: “Será que agora vou saber o que estou fazendo quando crio aquela entrada TXT, ou CNAME quando sigo um procedimento?”. Fique tranquilo, após a leitura, terá todos os conceitos práticos necessários para saber exatamente o que está fazendo quando tiver que realizar qualquer mudança no DNS. E provavelmente você deve ter tido aula (ou apenas passou na prova) em seu curso técnico ou universitário, mas na hora de pôr a mão na massa no DNS, prefere pedir para alguém ou seguir aquela ‘receitinha’. Vamos acabar com isso hoje! Todos que estão lendo devem saber para que serve DNS: traduzir nome para IP, para que usemos nomes e não IP em uma aplicação como browser, shell, cliente de e-mail ou qualquer outro software. Você verá que é muito mais que isso. E muitos devem ter visto (na apresentação do professor) o desenho abaixo: Esqueça ele, por enquanto. Provavelmente você nunca terá que se preocupar com esse conceito, para 99% dos profissionais de TI são dispensáveis, mesmo sendo o único que todo professor ensina =D! Primeiro, é importante entender a realidade em que o DNS foi feito e quais problemas ele tenta resolver. Abaixo uma lista de verdades que explicam muita coisa: DNS foi criado na década de 1980, quando os recursos computacionais eram muito mais limitados que hoje; Foi criado para o controle ser centralizado; E a carga maior ser descentralizada. O segundo conceito, importante, é: Existem dois tipos de servidores DNS: O que todos usam sempre, o DNS ‘Resolver’ e O que temos medo de mexer, o ‘SOA’. O Servidor Resolver (do inglês “Resolvedor”) é aquele que configuramos em nossa placa de rede (ou recebemos via DHCP). Usamos para resolver/consultar nomes DNS de qualquer domínio, para que possamos navegar na Internet ou fazer uso das nossas aplicações. Subir um servidor DNS é muito simples, o roteador WIFI que temos em casa quase sempre faz essa função de servidor DNS para nós. A nossa operadora sempre nos oferece ao menos 2 servidores DNS de consulta, para nosso uso da Internet contratada. Quando configuramos um Servidor Resolver? No roteador da nossa casa; Quando vamos compartilhar Internet em nossas impressoras (isso pode inclusive ajudar no desempenho quando fazemos cache, pois evita consulta na Internet de requisições repetidas). Já os servidores SOA são os servidores responsáveis por responder para Internet (para os servidores de Resolver) cada nome de nosso domínio para IPs. Por exemplo, o domínio darede.com.br que temos registrado para nosso uso, precisa de servidores SOA, também ao menos dois, para que possamos apontar entradas DNS como www, mail, smtp, etc, para os IPs onde essas aplicações rodam. Mas por que sempre ao menos dois? Nem vou responder Nosso servidor DNS de consulta pode verificar algum outro DNS de consulta, como os do provedor, ou resolver diretamente usando o protocolo WHOIS. Esse ai (WHOIS) foi outro que dá aquela dor no estômago quando vê né? Saaaabe o que é…. mas não sabe explicar? 😉 WHOIS é um protocolo utilizado principalmente para: “Informar aos servidores DNS Resolvers quem são os SOA de determinado domínio”. Aqui vem a sacada do DNS. Existem bilhares de entradas nos milhares de SOA, a IANA que controla a internet precisa apenas ter o controle de qual SOA reponde por cada domínio, enquanto nós ficamos responsáveis pelo SOA e suas centenas de entradas. Muitos devem conhecer, mas usando serviços como os abaixo, conseguimos saber quem (who is) o servidor SOA do domínio xpto.com.br, além de outras informações do mantenedor do domínio: registro.br who.is Comando Whois que pode ser instalado no Linux e Windows: Uma vez que o Servidor Resolver sabe quem manda no domínio (xpto.com.br), ele faz a consulta diretamente para o SOA. E agora a pergunta é: “Eu sei que você manda no domínio xpto.com.br. Quem é o www?” Então, o fluxo de uma consulta DNS no dia a dia da Internet fica o seguinte: Cliente pergunta a seu servidor DNS Resolver: “Qual IP de www.darede.com.br?” Servidor DNS Resolver 1, que tem encaminhamento para outro Servidor DNS Resolver (2), pergunta: “Qual IP de www.darede.com.br?” Servidor DNS Resolver 2, que não faz encaminhamento, utiliza o protocolo WHOIS para questionar: “Quem é o SOA de darede.com.br?” Com os IPs do SOA, o Servidor DNS Resolver 2 pergunta à um dos SOAs: Eu sei que você é SOA de darede.com.br, qual o IP de www?” Agora que o Servidor DNS Resolver 2 sabe o IP de www.darede.com.br, ele informa o cliente (ou ao Servidor DNS Resolver 1) qual é o IP e pode ou não configurar para cachear esse nome” Registrar: O Registrar é o órgão responsável por manter a concessão dos domínios usados na Internet. É ele quem configura o WHOIS Server de modo que os servidores DNS Resolvers possam ‘descobrir’ os SOAs de cada domínio. No Brasil, possuímos apenas um registrar, o registro.br, é nele que registramos o domínio para podermos usá-lo. Em outros países podem existir diversos Registrars, nos EUA, por exemplo, os provedores de hospedagem de sites são os próprios registrar. Já por aqui, no Brasil, os provedores de hospedagem de site fazem apenas o papel de SOA, servidor de e-mail, servidor de páginas web, etc. Agora que entendemos o fluxo das consultas DNS na Internet, sabemos que funciona assim, como abaixo: Os clientes consultam seu DNS Resolver procurando pelo IP de www.xpto.com.br; O WHOIS mantém os SOAs que respondem para cada domínio; O SOA mantém a tabela de nomes e IPs do domínio xpto.com.br; Os Servidores DNS Resolvers consultam WHOIS (Quem é) SOA de xpto.com.br; Os Servidores DNS Resolvers consultam ao SOA qual o IP de www.xpto.com.br; Cliente faz a requisição (HTTP, POP, SMTP, etc) ao IP de www.xpto.com.br Até então, falamos apenas de solução de nomes para IP, mas não existe apenas esse tipo de resposta.

Arquitetura Docker

Por Thiago Marques O pai ta on!! Até agora entendemos o que é um container, como o Docker funciona sob esse modelo e como utilizar o Docker Compose para auxiliar a criação de várias máquinas. Mas conforme vamos nos aprofundando surgem novas dúvidas, como: • Beleza, mas como tudo isso funciona? • Como o Docker controla e gerencia os containers? • Existe licenciamento para utilizar? Nesse post iremos detalhar um pouco mais sobre o conceito da plataforma para entender tudo isso. A Arquitetura Docker Fonte Docker Client / Remote API Quando estamos logados em um terminal e executamos comandos como docker ps, docker images e etc, utilizamos o command line interface (CLI) do docker, de forma que, nessas condições, podemos dizer que nosso terminal é um docker client. Assim conseguimos interagir com o daemon que está no host para nos trazer informações dos containers, das imagens e etc. Além do cliente, é possível interagir também via remote API. Quanto utilizamos o docker em uma máquina diferente do Jenkins, por exemplo, precisamos efetuar a configuração de um remote API para o deploy de um build funcionar. Note que para instalação do cliente/server em uma instância Amazon Linux 2, é necessário instalar via amazon-linux-extras. A AWS já possui uma excelente documentação de como fazer isso basta acessar o link: How-to-install-docker-Amazon-Linux Docker daemon / runtimes Depois da versão 1.11 do Docker (que até então era um grande monolítico), ele passou a segmentar em daemons as operações, sendo: • dockerd ficou responsável por receber e interpretar os comandos e APIs do cliente; • containerd ficou com o trabalho mais ‘pesado’ de controlar as imagens e containers, e executar os processos do runC; • runC que é quem de fato lida com o gerenciamento dos containers. Note que com a segmentação e a disponibilização dos códigos, podem existir outros runtimes para essas funções, como é o caso do CRI-O, que é uma alternativa ao containerd, ou o CRUN e o RAILCAR que são alternativas ao runC. NaAWS os runtimes utilizados pelo Fargate são o containerd e o runC. Fonte: Docker Docker Registry Finalizando a parte de arquitetura temos os Registries, que são os repositórios de onde é possível realizar o download/upload dos docker images. Veja na imagem inicial desse post que quando fazemos o primeiro pull (docker pull ) o processo seguido é: Nesse caso (apenas o pull) o containerd se registra no repositório, procura a imagem, e faz seu download para o repositório local. O runC não entra no processo ainda, pois não estamos de fato criando um container, apenas baixando a imagem. A vantagem de ter um repositório central, além de te poupar espaço, é que ele pode garantir outras características como: • Ter um repositório privado; • Possibilidade de utilizar SSO e colaboração; • Acesso a imagens oficiais; • Scan de vulnerabilidades para as imagens; • Integração com CI/CDs. Atualmente o Docker Hub, é o repositório mais utilizado, no qual você pode realizar o push (enviar) ou o pull (receber) as imagens, e possui a versão paga e gratuita. Obviamente na versão gratuita você tem alguns limites, como o bloqueio de 100 pulls por 6horas (veja os limites aqui) A AWS possui a sua própria solução de registry chamada ECR, o que se mostra ser eficiente para integração de serviços como o ECS e o Fargate. Contudo soluções como o Harbor, para IaaS também pode ser uma saída interessante caso você utiliza pull de forma constante. That’s all folks! Be Happy!!! Veja os outros artigos sobre Docker! Entendendo Docker Docker Compose

Nós usamos cookies para garantir e oferecer a melhor experiência de navegação em nosso site! Mais informações