.NET
Cloud Native e Cloud Agnostic
para rodar .NET em qualquer Cloud
ou sem Cloud sempre de forma profissional!
Últimas publicações
Aqui estão os últimos 12 posts de mais de 500…
Oragon Spring 2.0
Finalmente trago o Spring.NET em seu fork Oragon.Spring para o .NET Standard 2.1 e ASP.NET Core 3.0. Nos últimos anos tenho me dedicado a falar mais de arquitetura de solução do que arquitetura de software em si. Cada vez que peso os estudos em uma das duas direções, me afasto da outra. E assim...
Proxy Reverso: Pra quê? Por quê?
Você já nos viu falando de Proxy Reverso, em geral usamos NGINX nessa tarefa, mas afinal? Pra quê isso? Por que "isso" é necessário? Para que fique claro, precisamos voltar no tempo e revisitar alguns assuntos. Vou dar uma pincelada em assuntos como DHCP, DNS, e alocação de portas. É fundamental...
The Microservices Journey – S1E2
No post passado eu citei alguns elementos que precisam ser levados em conta, e não detalhei muita coisa. Só narrei causa e efeito. Hoje eu vou listar o material que já produzi que tem alguma ligação com o tema. Direta ou indiretamente, são elementos que vão ajudar a esclarecer como essa jornada, e...
The Microservices Journey – S1E1
Ainda não estruturei como uma jornada, portanto o começo dessa jornada é um brainstorm. Como toda jornada onde sabemos o destino, mas temos um caminho desconhecido, vamos buscando do horizonte curto para o distante e do horizonte distante para o curto, aproximando e reduzindo a área de...
Consciência Crítica vs Comportamento de Manada
Tomar decisões implica, ou deveria implicar, em conhecimento prévio somado ao discernimento e ponderação a respeito dos impactos e reflexos de cada decisão. Se você não está ponderando sobre suas próprias decisões, alguém está fazendo por você. Direta ou indiretamente. Nos resta saber se estamos...
Docker – de A a Z – 20 – Volume TMPFS – o poder do file system em memória
Uma das coisas lindas do Linux é a separação volumes e file system. E você não faz ideia do que dá para fazer com file system em memória!!!? No windows quando escrevemos no C: sabemos que estamos escrevendo em um disco ou no máximo em um raid. Não importa qual path seja. No linux, não é assim que...
Azure na Prática
Bom, você não está aqui à toa, você me conhece. Muito provavelmente você também conhece essa galera que está montando um treinamento focado em Azure, o Azure na Prática. O Azure na Prática surgiu de necessidades observadas pelos palestrantes e Microsoft MVPs Ericson da Fonseca, Milton Camara Gomes...
Dev Desktop – Fresh Setup – Windows Features & Tools
As vezes me peguntam sobre meu setup. Bom, nessa última semana por conta das ferramentas de produção e gravação de vídeos acabei por optar por formatar meu desktop principal. Para quem, como eu, instala e testa muita coisa, realizar um fresh install e configurar o ambiente do zero é uma tarefa que...
Entendendo Docker
Afinal, o que é essa sopa de letrinhas? Docker, dockerd / daemon, Docker Toolbox, Docker for Windows, Docker Desktop, céus, é tanto nome! Windows Containers, Linux Containers, Windows Subsystem for Linux (WSL), WSL2 e o Kernel linux embarcado no windows, lightweight virtual machines, docker...
O fim do IIS
Talvez você esteja acostumado com o Internet Information Services, talvez conheça-o, assim como eu, desde o tempo do Personal Web Server. Entre amor e ódio o IIS ajudou muita gente, mas seus dias de apogeu estão chegando ao fim. TL;DR; IIS morreu ou vai morrer? Não! Mas você precisa abrir os olhos...
Desenvolvimento de Software: Não deixe seu código-fonte contar mentiras para outros programadores
No telegram fazendo suporte à comunidade, acabei me deparando com um exemplo que me chamou muita a atenção. Um código que mentia. E vamos às minhas colocações sobre a questão: Sobre as abstrações Eu citei abstrações em Abstrações – Tradeoffs e co-responsabilidade, também falei sobre a absorção de...
Isso não é microsserviço!
No post passado eu introduzi uma analogia sobre o automobilismo profissional, e como os avanços tecnológicos chegam ao nosso dia-a-dia como consumidores de automotivos, carros de passeio. Preambulo A ideia foi contrastar duas realidades: Early Adopters com dinheiro infinito e nós, mundanos com...
Projetos Open Source
projetos ativos e projetos antigos disponíveis para estudo
Nenhum resultado encontrado
A página que você solicitou não foi encontrada. Tente refinar sua pesquisa, ou use a navegação acima para localizar a postagem.
Entender | Analisar | Projetar | Desenvolver | Implantar | Manter
A segurança que você busca não está em um tutorialPara entender uma tecnologia é importante entender o que influenciou sua criação, o que ela faz de fato, como ela faz. Para que então se sinta seguro e confiante a respeito das decisões que está prestes a tomar.
De um lado precisamos compreender o que está sendo feito por baixo dos panos para descobrir como extrair o máximo de uma tecnologia ou, ao menos, não atrapalhar o bom funcionamento dela.
O Cloud Native .NET é uma jornada de descoberta sobre tecnologias e patterns que fazem parte da maioria dos softwares que usamos, que somos usuários e que suportam e toleram altas cargas de trabalho, de forma eficaz, eficiente e sustentável.
É primeiro entendendo o que eles fazem, que podemos descobrir oportunidades e evoluir no que fazemos…
Conteúdo
Azure na Prática
Bom, você não está aqui à toa, você me conhece. Muito provavelmente você também conhece essa galera que está montando um treinamento focado em Azure, o Azure na Prática. O Azure na Prática surgiu de necessidades observadas pelos palestrantes e Microsoft MVPs Ericson da Fonseca, Milton Camara Gomes...
Dev Desktop – Fresh Setup – Windows Features & Tools
As vezes me peguntam sobre meu setup. Bom, nessa última semana por conta das ferramentas de produção e gravação de vídeos acabei por optar por formatar meu desktop principal. Para quem, como eu, instala e testa muita coisa, realizar um fresh install e configurar o ambiente do zero é uma tarefa que...
Entendendo Docker
Afinal, o que é essa sopa de letrinhas? Docker, dockerd / daemon, Docker Toolbox, Docker for Windows, Docker Desktop, céus, é tanto nome! Windows Containers, Linux Containers, Windows Subsystem for Linux (WSL), WSL2 e o Kernel linux embarcado no windows, lightweight virtual machines, docker...
O fim do IIS
Talvez você esteja acostumado com o Internet Information Services, talvez conheça-o, assim como eu, desde o tempo do Personal Web Server. Entre amor e ódio o IIS ajudou muita gente, mas seus dias de apogeu estão chegando ao fim. TL;DR; IIS morreu ou vai morrer? Não! Mas você precisa abrir os olhos...
Desenvolvimento de Software: Não deixe seu código-fonte contar mentiras para outros programadores
No telegram fazendo suporte à comunidade, acabei me deparando com um exemplo que me chamou muita a atenção. Um código que mentia. E vamos às minhas colocações sobre a questão: Sobre as abstrações Eu citei abstrações em Abstrações – Tradeoffs e co-responsabilidade, também falei sobre a absorção de...
Isso não é microsserviço!
No post passado eu introduzi uma analogia sobre o automobilismo profissional, e como os avanços tecnológicos chegam ao nosso dia-a-dia como consumidores de automotivos, carros de passeio. Preambulo A ideia foi contrastar duas realidades: Early Adopters com dinheiro infinito e nós, mundanos com...
Sobre Formula 1 e Microsserviços
A busca pelo Santo Graal, agora personificado nos microsserviços, causa uma euforia semelhante ao que víamos nas filas de pessoas dando voltas em quadras, em véspera de lançamento do iPhone. Hoje microsserviços virou uma febre, o que é intuitivo e natural, mas nem de longe é racional. Antes de...
DevHero – Resumo
Pessoal, carreira dev nunca foi a menina dos olhos e nunca foi um tema que eu tivesse interesse de abordar, mas alguns pedidos me chamam a atenção então vou fazer um mega resumo do que do DevHero 2019. Para quem não faz ideia do que é o DevHero, o evento foi um evento de 1 semana voltado para...
Oragon Design Guide – Agnostic Services
Seu serviço deve rodar sob qualquer host, ou sem host (como uma dependência de library), com qualquer tecnologia, e não deve precisar de modificações quando novas tecnologia são lançadas. Óbvio que estamos falando de algo a perseguir e não uma regra absoluta e/ou intransigente. História Embora a...
Eu tentei, tentei muito e falhei
Pessoal, vou contar um pouco da minha história, mais especificamente um subset, acho importante mostrar como algumas coisas se desenharam ao longo desses anos, e acredito que esteja perto de algo muito, muito grandioso. Esse post trata da minha história com Linux, com Docker e com todo o processo...
Oragon – Princípios de Design – Complexidade Reside na Arquitetura
Alguns poucos lembram, pois alguns poucos estavam lá, mas quando comecei minha carreira profissional. Uma das coisas que me projetou rápido na Petrobras foi a capacidade de identificar padrões e automatizar via abstrações e componentes a escrita de código repetitivo e burocrático. Ainda no ASP...
Global DevOps Bootcamp @ Le Wagon & Coders In Rio
Vai rolar amanhã o Global DevOps Bootcamp na Le Wagon - Sábado, 15 de Junho 2019 - 10 às 17h REGISTRATION PAGE!! PESSOAL FAÇAM O REGISTRO NO EVENTBRITE DO EVENTO https://www.eventbrite.com/e/global-devops-bootcamp-le-wagon-coders-in-rio-tickets-61031261145 AGENDA DO EVENTO 09:00 - ABERTURA DO...
Conheça nosso Podcast
DevShow PodcastEm 2019 resolvemos criar um podcast, o DevShow Podcast, desde lá são mais de 40 episódios com muito assunto legal, sempre com essa pegada pessoal, falando coisas sérias, mas sem o menor compromisso com a formalidade.
.NET
Spring.NET o Renascimento
Quem me acompanha, principalmente já viu ou participou de alguma solução minha na última década, sabe que o Spring.NET é meu fiel escudeiro. Há motivos de sobra para não me desapegar do projeto, no entanto recorrentemente testo novas alternativas. Entretanto, mais de uma década após os primeiros flertes, ainda é meu container favorito, e por isso merece uma menção honrosa não só no blog, mas na minha carreira como um todo. Muito do que fiz com .NET nos últimos anos não seria economicamente viável sem ele.
Docker – de A a Z – 19 – Youtube Downloader – Novidades #01
Pessoal, esse é o primeiro pacote com novidades sobre o projeto. Nosso diagrama de causa-efeito-ação chega a sua 5a versão com muitas novidades, incluindo:Adição do MongoDB, agora fazendo encoding de MP3 com FFMPEG, possibilitando o download de MP3 que já está em dev, além de stream parcial (que permite utilizar o controle de tempo da tag video do html5) e várias correções, além de uma nova implementação “duvidosa”. Mas essa eu não vou contar aqui, você terá de olhar no github, mais especificamente em um commit que nesse momento só está presente na develop.
Fique atento às modificações nas imagens abaixo. Essas imagens representam novidades que criei e estão publicadas em dev (http://devweek04.gago.io:20001/), enquanto isso prd (http://devweek04.gago.io/) continua com a mesma implementação antiga. Nesse momento faz bem deixar assim, já que torna possível visualizar as diferenças.
Docker – de A a Z – 19 – Youtube Downloader – o projeto
Olá, esse é o vídeo de número 19 da série e vamos abordar um tema incomum: Pizza! Oops brincadeira! Youtube Downloader! A escolha desse projeto se dá pela necessidade de utilizar paralelismo para processar as requisições de download, tratar-se de um projeto não convencional, e precisar de cuidados ortogonais quanto ao design da solução em si. São elementos que fazem desse projeto um projeto divertido e cheio de peculiaridades. A principal característica é sair do mais do mesmo, dos cruds com MongoDB e Redis e mostrar um exemplo mais rico. ler mais…
Docker – de A a Z – 14 – ASP.NET Core from Scratch to Production with docker & jenkins (pt-BR)
Apresento aqui um projeto ASP.NET Core, desde sua criação até sua chegada a produção, com jenkins.
Começamos apresentando as opções de criação do projeto, depois habilitamos a integração com o Docker for Windows. Em seguida adicionamos mongodb ao projeto e começamos a desenhar o build de produção, ainda na máquina de desenvolvimento. Ao concluir o processo de configuração, subo o código para o github e faço o build no jenkins, usando pipeline para realizar build e deploy da nossa aplicação ASP.NET Core.
Escassez de documentação, entenda como as coisas funcionam
Se você não é capaz de entender uma implementação lendo código, é bom começar. Mesmo que por hobby, ler código lhe fará entender melhor como as coisas funcionam, ou pelo menos lhe dar mais opções na hora de avaliar alguma implementação. Há inúmeros projetos Open Source bem documentados, no entanto quando se depara com algo recente, a escassez de documentação é uma realidade dolorosa.
Ao encontrar um projeto relevante, provavelmente buscará um tutorial, ou algo que te aproxime do entendimento, mas nem sempre esse tipo de material está disponível. Há momentos que você quer algo específico e também não encontra conteúdo indexado no google. Há momentos em que você só quer entender como um pedaço do projeto foi feito, para entender como alguns problemas são resolvidos, quais padrões foram usados, enfim, como foi feito. Ler código é importantíssimo.
Arquitetura
Dapr – Distributed Application Runtime – Primeiras Impressões
Nessa quarta-feira a Microsoft anunciou no Open Source Blog um projeto curioso chamado Dapr. Entre os principais pontos, o que me chama a atenção é que tem muita cara de servidor de aplicação/componente. E isso de certa forma me chama a atenção pelas possibilidades.
Na versão alpha, versão atual, vemos alguns building blocks muito interessantes, como:
- Service-to-service Invocation
- State Management
- Pub/Sub
- Resource Binding & Triggers
- Actors
- Distributed Tracing
- Extensibility
Valle lembrar que o projeto está na versão 0.1.0, e nada do que temos agora é compromisso firmado com a versão final, eles deixam isso bem claro. Ainda está em alpha.
O post original está aqui Announcing Distributed Application Runtime (Dapr), an open source project to make it easier for every developer to build microservice applications e apenas vou traduzir algumas partes para dar prosseguimento aos comentários.
Diagnóstico e motivação
| It is remarkable to see the transformation over the last few years as more and more developers build scalable, cloud native applications, taking advantage of managed services to deploy and run them. With this transformation, microservice architectures have become the standard for building cloud native applications, and it is predicted that by 2022, 90% of new apps will feature microservice architectures. A microservice architecture offers compelling benefits, including scalability, loose service coupling and independent deployments. However, this approach can come at a high cost of understanding and skilling on distributed systems. Developers want to focus on business logic, frequently and incrementally migrating legacy code, while leaning on the platforms to provide their applications with the required scale, resiliency, maintainability, elasticity and the other attributes of cloud-native architectures. What developers find though, is limited portability between cloud and edge and they continually end up solving the same distributed system problems such as state management, resilient method calling and handling events. In addition, many programming runtimes often have narrow language support and tightly controlled feature sets, making it challenging to build microservice architectures. | É notável ver a transformação nos últimos anos, à medida que mais e mais desenvolvedores criam aplicações escaláveis cloud native, aproveitando os serviços gerenciados para implantá-los e executá-los. Com essa transformação, as arquiteturas de microsserviço tornaram-se o padrão para a criação de aplicações nativos da nuvem, e prevê-se que até 2022, 90% dos novas aplicações apresentem arquiteturas de microsserviço. Uma arquitetura de microsserviço oferece benefícios atraentes, incluindo escalabilidade, acoplamento de serviço flexível e implantações independentes. No entanto, essa abordagem pode ter um alto custo de entendimento e habilidade em sistemas distribuídos. Os desenvolvedores desejam se concentrar na lógica de negócios, migrando com frequência e incrementalmente o código legado, enquanto se apoiam nas plataformas para fornecer às aplicações a escala, resiliência, capacidade de manutenção, elasticidade e outros atributos necessários das arquiteturas nativas da nuvem. O que os desenvolvedores descobrem é a portabilidade limitada entre a nuvem e a borda e eles acabam resolvendo os mesmos problemas de sistema distribuído, como gerenciamento de estado, chamada de método resiliente e manipulação de eventos. Além disso, muitos tempos de execução de programação geralmente têm suporte a idiomas estreitos e conjuntos de recursos rigidamente controlados, tornando difícil a construção de arquiteturas de microsserviços. |
Dapr: Microservice building blocks for cloud and edge
| Dapr is an open source, portable, event-driven runtime that makes it easy for developers to build resilient, microservice stateless and stateful applications that run on the cloud and edge. Dapr embraces the diversity of all programming languages and developer frameworks and simplifies building applications such as the e-commerce example. Dapr consists of a set of building blocks accessed by standard HTTP or gRPC APIs that can be called from any programming language. These building blocks empower all developers with proven, industry best practices and each building block is independent; you can use one, some, or all of them in your applications. In addition, through the open source project, we welcome the community to add new building blocks and contribute new components into existing ones. Dapr is completely platform agnostic, meaning you can run your applications locally, on any Kubernetes cluster, and other hosting environments that Dapr integrates with. This enables developers to build microservice applications that can run on both the cloud and edge with no code changes. | O Dapr é um runtime de código aberto, portátil e orientado a eventos, que facilita para os desenvolvedores a criação de aplicações resilientes, sem estado e sem estado de microsserviço, executados na nuvem e na borda. O Dapr abraça a diversidade de todas as linguagens de programação e estruturas de desenvolvedores e simplifica a criação de aplicações como o exemplo do comércio eletrônico. O Dapr consiste em um conjunto de blocos de construção acessados pelas APIs HTTP ou gRPC padrão que podem ser chamadas a partir de qualquer linguagem de programação. Esses blocos de construção capacitam todos os desenvolvedores com as melhores práticas comprovadas do setor e cada bloco de construção é independente; você pode usar um, alguns ou todos eles em suas aplicações. Além disso, por meio do projeto de código aberto, damos as boas-vindas à comunidade para adicionar novos componentes e contribuir com novos componentes nos já existentes. O Dapr é totalmente independente da plataforma, o que significa que você pode executar suas aplicações localmente, em qualquer cluster Kubernetes e em outros ambientes de hospedagem aos quais o Dapr se integra. Isso permite que os desenvolvedores criem aplicações baseadas em microsserviço que podem ser executados na nuvem e na borda sem alterações de código. |
Get Started e Primeiras Impressões
A home do projeto está disponível em dapr.io. De lá o get started nos leva para o github do projeto onde encontramos alguns poucos links, mas o principal é o configure Dapr locally. Não depender do Kubernetes é um ponto alto para o projeto. Poder rodar com Docker puro, faz diferença, e dá a dimensão de que sim, é capaz de rodar em qualquer lugar, sem nos empurrar para o uso do Kubernetes.
Vale lembrar que Kubernetes embora seja standard, diversos grandes nomes da comunidade nacional e internacional não recomendam k8s para a maioria dos workloads pequenos. Nesses cenários docker swarm atende perfeitamente, e tem melhor fit. Consideramos workloads pequenos, até 7 nós masters em um cluster (detalhes). Entre os nomes que respaldam essa afirmação está Bret Fisher, um Docker Captain (detalhes sobre essa treta)
A configuração inicial é super simples, consiste em instalar uma CLI. Eu optei pelo setup com powershell pois, como eu já imaginava, uma vez instalado, poderia ser executado a partir do bash com windows terminal. Então essa foi minha opção.
Uma vez com a CLI instalada foi hora de instalar o runtime. Super simples também.

Agora era hora de rodar os samples, e ver como funciona.
Segui o passo-a-passo do primeiro hello world e tudo funcionou de primeira.
Para uma versão alpha eu achei o projeto incrível. Vale lembrar que o Hello workd é em NodeJS. A propósito, se for rodar a demo, não deixe de rodar npm install na pasta da demo.

É assim que começa “o jogo”. Uma vez sem container nenhum rodando, basta rodar dapr init para que os containers sejam inicializados. O próximo passo é rodar sua aplicação.
dapr run --app-id mynode --app-port 3000 --port 3500 node app.js
Note que ao rodar, você já enxerga um log no console estruturado como todo bom application server.

Entendendo sua arquitetura
Um das coisas que me chamou a atenção era a falta de um dockerfile no projeto node, e a necessidade de rodar um npm install no windows.
Enquanto eu esperava que mesmo que a CLI rodasse no windows, TODO o workload seria executado completamente no Linux, em containers docker. Mas a abordagem escolhida pelo projeto ainda nessa versão alpha é diferente. Nessa versão (e não há nada que eu tenha lido que aponta para uma mudança) o seu projeto é executado junto com a CLI. Assim, se a CLI está no Windows, o daprd também está no windows, e consequentemente sua aplicação roda no Windows. Por outro lado, recursos adicionais são executados diretamente no linux. Como o redis e uma instância do dapr.
E rodando estão os seguintes processos

Isso me chamou muito a atenção, pois a aplicação está rodando no Windows e apenas consumindo serviços hospedados com docker.
Nessa imagem fica claro que a CLI dapr está chamando o daprd (daemon) que hospeda algum serviço de comunicação, como um sidecar para minha aplicação node.
Essa topologia é descrita aqui:

Do outro lado, alguns serviços são hospedados como containers mas fazem parte da infraestrutura do daprd.
E assim nasce um modelo super interessante e funcional.
O máximo que pude ver foi essa conectividade, a parte de armazenamento de estado (ainda não dá para chamar de gerenciamento pois estado é controlado de forma ativa), mas enfim, já temos grandes avanços, muito interessantes. E dá para vislumbrar muito potencial para o projeto.
Outra característica muito relevante é a afinidade e proximidade com gRPC como protocolo de comunicação entre os nossos serviços e o dapr. Essa iteração vem dando poder e respaldo ao gRPC e apresenta, inclusive, um novo modelo de uso, muito interessante.
Ainda faltam dashboards, faltam algumas coisas para consolidar essa estratégia mas o que vemos já é fantástico.

Em linhas gerais esses são os serviços providos nessa versão alpha. Acredito e imagino que esses mesmos serviços vão ganhando capacidades, e suas implementações passam a ser mais amigáveis e automáticas.

A estratégia de deploy que utilizei é bem parecida com a imagem acima.
No entanto o projeto também está disponível para ser executado em clusters Kubernetes, como mostra a imagem abaixo:

O que eu tinha para apresentar do projeto hoje era só isso.
Vale a pena o teste, mas como o próprio site diz: ainda é cedo para pensar em produção. Mas já há uma boa oportunidade para contribuir com o projeto.
Open Application Model
2019 tem sido um ano intenso, cheio de novidades e muitos novos padrões e standards. Kubernetes já se consolidou como plataforma de orquestração default há alguns anos e agora o movimento que vemos é na linha de criação de standards sobre o Kubernetes. Por outro lado, essa nova leva de padrões e especificações oferece um modelo de aplicações e serviços dinamicamente alocáveis, conectáveis e desalocáveis que parece vir de um futuro muito, mas muito distante. São iniciativas interessantes que muito provavelmente ainda sofrerão mutações e algumas fusões no percurso, mas que oferecem imenso potencial para viajarmos nas possibilidades de um futuro nem tão distante assim.
Assim começamos com o Open Application Model.
ler mais…
Post Resposta: POR QUE ADOTAR KAFKA PARA MENSAGERIA?
Esse é um post resposta ao post POR QUE ADOTAR KAFKA PARA MENSAGERIA? do Elemar JR no site da Eximia, sua empresa.
A resposta estava ficando longa demais, e resolvi transformar em post. Principalmente por se tratar de um conteúdo (RabbitMQ) que está no meu toolset, assim como Kafka está para entrar. Vou aproveitar para usar essas resposta para compor a seqüência de posts da série RabbitMQ de A a Z, pois essa questão RabbitMQ vs Kafka foi um tema solicitado pela audiência e não foi respondida na época.
ler mais…
Proxy Reverso: Pra quê? Por quê?
Você já nos viu falando de Proxy Reverso, em geral usamos NGINX nessa tarefa, mas afinal? Pra quê isso? Por que “isso” é necessário?
ler mais…
The Microservices Journey – S1E2
No post passado eu citei alguns elementos que precisam ser levados em conta, e não detalhei muita coisa. Só narrei causa e efeito. Hoje eu vou listar o material que já produzi que tem alguma ligação com o tema. Direta ou indiretamente, são elementos que vão ajudar a esclarecer como essa jornada, e mostrar como tudo começou para mim. Eu me proponho a elucidar alguns pontos que vão ajudar a esclarecer e te ajudar a construir soluções melhores.
ler mais…Containers
Docker – de A a Z – 15 – RabbitMQ, ElasticSearch , LogStash e Kibana
Durante a série Docker de A a Z, esse foi um dos Stacks entregues para facilitar a compreensão de como docker pode nos ajudar a unir soluções complexas, colaborando para criar stacks com diversos projetos e produtos.
Esse stack serviu para a apresentação, mas também virou projeto e hoje é mantido e atualizado, por mim e por colaborações.
Para simplificar a apresentação desse conteúdo o post foi movido para a página do Stack aqui no site.
Docker Images – Nginx & Google PageSpeed
A internet como vemos hoje exige cada vez mais performance e cada vez melhor usabilidade. Nunca tivemos tanto apreço à experiência do usuário, assim produtos, ferramentas, serviços e frameworks são bem vindos para ajudar a entregar performance. Com o aumento nos recursos de interface, e a facilidade com que conseguimos hardware, chegamos em um momento em que a renderização passa a ser um ponto chave na obtenção de performance, já que do aspecto de processamento do server, nunca vimos tanto hardware (barato), nunca vimos tantos patterns, tantas soluções para facilitar nossa vida.
Mas e quando você não tem controle sobre todo o que foi desenvolvido? Seja ao fazer deploy de um WordPress, Magento, ou soluções maiores, como SiteCore, Evoq, o que fazer quando você precisa melhorar a experiência do seu usuário? Esse problema é comum quando usamos soluções prontas, em que sua customização não necessariamente abrange detalhes tão técnicos. É sobre esse tipo de problema que quero falar e vou aproveitar para apresentar o Google PageSpeed Module for Nginx, falar um pouco sobre Nginx e como ambos podem te ajudar no seu próximo projeto.
Docker – de A a Z – 13 – Bridge Network
Olá pessoal,
nesse vídeo vou abordar as diferenças entre Default Bridge Network e redes User Defined Bridge Networks, as redes que geralmente criamos para nossos containers. As diferenças entre as redes bridge padrão e as que você cria é a capacidade de realizar descoberta de containers com base em seu nome. Isso significa que se você tem o container A e o container B na rede bridge padrão, precisará usar o IP ou utilizar de o parâmetro –link durante a criação do container. Esse trabalho não é necessário se você criar uma rede e adicionar esses dois containers. Os nomes A e B são visíveis a ambos e a resolução do IP de um dos nomes resulta no IP do container correto. Essa não é uma diferença sutil, é significativa e facilita a vida na hora de criarmos serviços que usam diversos containers.
Esse vídeo foi criado para exemplificar como isso funciona. De qualquer forma, se quiser criar uma rede no Docker é muito simples, basta digitar:
# criando uma nova rede bridge docker network create -d bridge [nome da rede] # conectando/desconectando um container à rede docker network [connect/disconnect] [nome da rede] [nome do container] #ou criando um container já em uma rede específica docker run ... --network=[nome da rede] ...
Esses exemplos são abordados nesse vídeo, curte lá!
Docker – de A a Z – 12 – Demo MongoDB no Docker
Pessoal, uma das demos mais pedidas, MongoDB no Docker. Nessa demo vou apresentar o setup do MongoDB com e sem autenticação. Ficou muito legal!
Docker – de A a Z – 11 – Demo MySQL e MariaDB no Docker
Mensageria
Nenhum resultado encontrado
A página que você solicitou não foi encontrada. Tente refinar sua pesquisa, ou use a navegação acima para localizar a postagem.
Conteúdo e Posicionamento
.NET + Cloud Native + Cloud Agnostic
.NET | DevOps | Microservices | Containers | Continuous Delivery
.NET muito além do .NET
O mínimo de infra que todo dev e/ou arquiteto deveria saber
Aplicações distribuídas e comunicação entre serviços (RabbitMQ / gRPC)
Containers, Docker e Kubernetes
RabbitMQ e Mensageria e comunicação assíncrona entre aplicações e serviços
Arquitetura de Software e Arquitetura de Solução com foco no melhor aproveitamento em projetos .NET
Nossos números
Desde 2002 trabalhando com desenvolvimento de software
Desde 2002 ajudando outros devs
Desde 2010 trabalhando exclusivamente como arquiteto
Contas atingidas no telegram/facebook
Alunos
Microsoft MVP
Conteúdo Gratuito
Tudo que está aqui no gaGO.io é conteúdo gratuito, feito para ajudar desenvolvedores dos mais variados níveis.
Cursos
Tenho também alguns programas de acompanhamento. Esses programas tem a função de ajudar desenvolvedores em áreas específicas ou de forma mais abrangente na jornada do arquiteto.
















