[{"content":"","date":"17 julho 2026","externalUrl":null,"permalink":"/tags/applicationset/","section":"Tags","summary":"","title":"Applicationset","type":"tags"},{"content":"O Argo CD sempre foi reconhecido por sua interface de usuário — árvore de recursos, status de sincronização em tempo real, visualização de diffs — que tornou o GitOps acessível para equipes que não vivem dentro de arquivos YAML. Os ApplicationSets, no entanto, sempre se encaixaram de forma estranha nesse cenário. Até agora.\nCom a versão 3.5, o Argo CD entrega uma interface de primeira classe para ApplicationSets, atendendo a uma solicitação de funcionalidade que acumulou 189 reações positivas na comunidade. Este artigo explora o que está sendo entregue e por que isso importa para equipes que gerenciam GitOps em escala.\nA lacuna de visibilidade dos ApplicationSets # ApplicationSets seguem um padrão de fábrica para Applications. Você escreve um único recurso que diz \u0026ldquo;para cada cluster que corresponda a esta label, gere uma Application a partir deste template\u0026rdquo;, e o controlador produz N Applications filhas. Um único ApplicationSet pode se espalhar por dezenas de clusters e centenas de repositórios.\nAntes da versão 3.5, os operadores tinham duas opções para inspecionar ApplicationSets: usar kubectl ou argocd appset no terminal, ou encapsular o ApplicationSet dentro de um App-of-Apps e navegar pela árvore de recursos da Application pai. Nenhuma das abordagens é ideal para ambientes de produção com dezenas ou centenas de ApplicationSets.\nO que a nova interface oferece # A nova interface é acessível pela rota /applicationsets e por um item dedicado na barra de navegação.\nListagem com controles familiares # A página de listagem de ApplicationSets segue o mesmo padrão da lista de Applications — busca por substring, filtros, gráfico de pizza com resumo de saúde e layout alternável. As políticas de RBAC são aplicadas exatamente como no CLI.\nÁrvore de recursos mostrando a genealogia # Cada ApplicationSet é exibido como um nó raiz, com cada Application gerada como um nó downstream. Clicar em uma Application filha leva diretamente para a página de detalhes, facilitando o rastreamento da relação entre o template gerador e suas instâncias implantadas.\nSaúde como campo de primeira classe # O controlador de ApplicationSet agora escreve status.health derivado das condições de status, com três estados possíveis: Healthy, Degraded e Progressing. As condições são expostas pela interface, dando aos operadores a mesma consciência de saúde que já possuem para Applications individuais.\nPainel lateral # Ao clicar em um nó de ApplicationSet ou no botão Details, um painel lateral é aberto com quatro abas: Summary, Manifest, Events e Preview.\nPreview do ApplicationSet # A aba Preview replica o comando argocd appset generate diretamente no navegador. É possível editar o YAML do ApplicationSet, alterar generators e executar o preview novamente. Três visualizações estão disponíveis: LIVE APPS (estado atual), DIFF (o que mudaria) e DESIRED APPS (saída gerada).\nPreview de App-of-AppSet # Para equipes que utilizam o padrão App-of-Apps, o preview também funciona a partir da Application pai, mostrando quais Applications filhas seriam alteradas na próxima sincronização.\nBadges de proprietário e nó raiz sintético # Applications filhas exibem um badge com o nome do ApplicationSet pai. Um ícone de nó raiz sintético pode ser ativado nas árvores de recursos das Applications filhas para contexto adicional.\nLimitações importantes # A interface de ApplicationSet é somente leitura nesta fase alpha. Operações de criação, atualização e exclusão continuam fluindo pelo Git, preservando o modelo Git como fonte única da verdade. O recurso está em alpha na versão 3.5, portanto a aparência e o comportamento podem mudar antes de atingir a versão estável.\nDisponibilidade: o release candidate do Argo CD 3.5 chega em 16 de junho de 2026, com disponibilidade geral em 4 de agosto de 2026.\nImpacto prático para equipes GitOps # Para organizações que gerenciam deployments multi-cluster com ApplicationSets, a nova interface preenche uma lacuna significativa de observabilidade. Operadores não precisam mais alternar entre terminal e interface gráfica para entender o estado de seus ApplicationSets. A visualização em árvore deixa imediatamente claro quais Applications um determinado generator produziu e se essas Applications estão saudáveis.\nO recurso de Preview é particularmente valioso para equipes que experimentam novos generators ou templates. Poder iterar sobre o spec do ApplicationSet e ver o diff ao vivo antes de fazer o commit reduz o ciclo de feedback de minutos para segundos.\nConclusão # A interface de ApplicationSets do Argo CD 3.5 é um marco para o projeto. Ela tira os ApplicationSets do universo exclusivo de YAML e os leva para a interface visual que tornou o Argo CD popular. Embora a versão alpha seja somente leitura, a base é sólida e atende às necessidades mais urgentes de visibilidade para operadores de ApplicationSets.\nNa EF-TECH, ajudamos empresas a implementar e gerenciar workflows GitOps com Argo CD em escala. Entre em contato.\n","date":"17 julho 2026","externalUrl":null,"permalink":"/pt-br/blog/argocd-appset-ui/","section":"Soluções em Cloud Computing","summary":"O Argo CD v3.5 finalmente entrega uma interface dedicada para ApplicationSets, atendendo a uma das solicitações mais antigas da comunidade. A nova interface inclui página de listagem com busca e filtros, árvore de recursos que mostra o relacionamento entre ApplicationSets e Applications geradas, status de saúde como campo de primeira classe, modo preview com YAML editável e badges de proprietário para rastreabilidade. Uma visão geral dos recursos e limitações.","title":"Argo CD 3.5 Lança Interface Dedicada para ApplicationSet: Gerenciando GitOps em Escala","type":"pt-br"},{"content":"Argo CD has long been celebrated for its user interface — resource trees, real-time sync status, clean diff views — which made GitOps accessible to teams that do not live in YAML. ApplicationSets, however, fit awkwardly into that picture. Until now.\nWith version 3.5, Argo CD ships a first-class ApplicationSet UI, addressing a feature request that accumulated 189 thumbs-up reactions. This article walks through what is shipping and why it matters for teams managing GitOps at scale.\nThe ApplicationSet visibility gap # ApplicationSets are a factory pattern for Applications. You write a single resource that says \u0026ldquo;for every cluster matching this label, generate an Application from this template,\u0026rdquo; and the controller produces N child Applications. A single ApplicationSet can fan out across dozens of clusters and hundreds of repositories.\nBefore 3.5, operators had two options to inspect ApplicationSets: use kubectl or argocd appset on the CLI, or wrap the ApplicationSet inside an App-of-Apps and browse through the parent Application\u0026rsquo;s resource tree. Neither approach is ideal for production environments running tens or hundreds of ApplicationSets.\nWhat the new UI brings # The new interface is accessible via the /applicationsets route and a dedicated navigation bar item.\nList page with familiar controls # The ApplicationSet list page mirrors the Application list — substring search, filters, a health-summary pie chart, and toggleable layouts. RBAC policies are enforced exactly as on the CLI.\nResource tree showing the family tree # Each ApplicationSet is displayed as a root node with every generated child Application as a downstream node. Clicking a child jumps directly to its details page, making it straightforward to trace the relationship between a generator template and its deployed instances.\nHealth as a first-class field # The ApplicationSet controller now writes status.health derived from status conditions, with three possible states: Healthy, Degraded, and Progressing. Conditions are exposed through the UI, giving operators the same health awareness they already have for individual Applications.\nSlide-out panel # Clicking an ApplicationSet node or its Details button opens a slide-out panel with four tabs: Summary, Manifest, Events, and Preview.\nApplicationSet Preview # The Preview tab mirrors argocd appset generate directly in the browser. You can edit the ApplicationSet spec YAML, change generators, and re-run the preview. Three views are available: LIVE APPS (current state), DIFF (what would change), and DESIRED APPS (generated output).\nApp-of-AppSet preview # For teams using the App-of-Apps pattern, the preview also works from the parent Application, showing which child Applications would change on the next sync.\nOwner badges and synthetic root node # Child Applications display an owner badge with the parent ApplicationSet name. A toggle-able synthetic root node icon can also be added to child Application resource trees for additional context.\nLimitations to keep in mind # The ApplicationSet UI is read-only in this alpha phase. Create, update, and delete operations still flow through Git, preserving the Git-as-source-of-truth model. The feature ships as alpha in 3.5, so look and behavior may change before reaching stable.\nAvailability: Argo CD 3.5 release candidate ships June 16, 2026, with general availability on August 4, 2026.\nPractical implications for GitOps teams # For organizations managing multi-cluster deployments with ApplicationSets, the new UI closes a significant observability gap. Operators no longer need to switch between CLI and UI to understand the state of their ApplicationSets. The resource tree visualization makes it immediately clear which Applications a given generator produced and whether those Applications are healthy.\nThe Preview feature is particularly valuable for teams experimenting with new generators or templates. Being able to iterate on the ApplicationSet spec and see the live diff before committing to Git reduces the feedback loop from minutes to seconds.\nConclusion # Argo CD 3.5\u0026rsquo;s ApplicationSet UI is a milestone for the project. It brings ApplicationSets out of the YAML-only realm and into the visual interface that made Argo CD popular in the first place. While the alpha release is read-only, the foundation is solid and addresses the most pressing visibility needs for ApplicationSet operators.\nAt EF-TECH, we help companies implement and manage GitOps workflows with Argo CD at scale. Contact us.\n","date":"17 julho 2026","externalUrl":null,"permalink":"/en/blog/argocd-appset-ui/","section":"Cloud Computing Solutions","summary":"Argo CD v3.5 ships a dedicated ApplicationSet UI after a long-running community request. The new interface includes list pages with search and filters, a resource tree showing parent-child relationships between ApplicationSets and generated Applications, first-class health status, an editable YAML preview mode, and owner badges for traceability. An overview of the features and limitations.","title":"Argo CD 3.5 Ships a Dedicated ApplicationSet UI: Managing GitOps at Scale","type":"en"},{"content":"","date":"17 julho 2026","externalUrl":null,"permalink":"/tags/argocd/","section":"Tags","summary":"","title":"Argocd","type":"tags"},{"content":"","date":"17 julho 2026","externalUrl":null,"permalink":"/en/blog/","section":"Cloud Computing Solutions","summary":"Articles and news about cloud computing, security, and DevOps from EF-TECH.","title":"Blog","type":"en"},{"content":"","date":"17 julho 2026","externalUrl":null,"permalink":"/pt-br/blog/","section":"Soluções em Cloud Computing","summary":"Artigos e novidades sobre cloud computing, segurança e DevOps da EF-TECH.","title":"Blog","type":"pt-br"},{"content":"","date":"17 julho 2026","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":" Cloud Computing Solutions # Boost your infrastructure performance and security with our solutions!\nAt EF-TECH, we specialize in cloud computing solutions that enhance performance, ensure business continuity, and optimize infrastructure costs. Whether it\u0026rsquo;s migration, automation, or ongoing management, our team delivers results that matter to your business.\nWhat We Do # Cloud Migration: Planning and execution of migration to AWS, Google Cloud, and Azure Security and Compliance: Firewall, WAF, SIEM, LGPD compliance, and disaster recovery DevOps and Automation: CI/CD, Infrastructure as Code, Kubernetes, and containers Managed Infrastructure: 24/7 monitoring, auto-scaling, and cost optimization GLPI: Open-source IT asset management and ITIL service desk with containerized deployment Why EF-TECH? # Certified team across major cloud platforms Focus on performance, security, and cost-effectiveness Personalized support for each client Dedicated technical support via GLPI portal Contact us and discover how we can help transform your infrastructure.\n","date":"17 julho 2026","externalUrl":null,"permalink":"/en/","section":"Cloud Computing Solutions","summary":"Boost your infrastructure performance and security with our solutions!","title":"Cloud Computing Solutions","type":"en"},{"content":"","date":"17 julho 2026","externalUrl":null,"permalink":"/","section":"EF-TECH","summary":"","title":"EF-TECH","type":"page"},{"content":"","date":"17 julho 2026","externalUrl":null,"permalink":"/tags/gitops/","section":"Tags","summary":"","title":"Gitops","type":"tags"},{"content":"","date":"17 julho 2026","externalUrl":null,"permalink":"/categories/infraestrutura/","section":"Categories","summary":"","title":"Infraestrutura","type":"categories"},{"content":"","date":"17 julho 2026","externalUrl":null,"permalink":"/categories/infrastructure/","section":"Categories","summary":"","title":"Infrastructure","type":"categories"},{"content":"","date":"17 julho 2026","externalUrl":null,"permalink":"/tags/kubernetes/","section":"Tags","summary":"","title":"Kubernetes","type":"tags"},{"content":" Soluções em Cloud Computing # Transforme a performance e a segurança do seu ambiente com nossas soluções!\nNa EF-TECH, especializamos em deliversolutions de cloud computing que elevam a performance, seguram a continuidade e otimizam custos da sua infraestrutura. Seja migração, automação ou gestão continua, nossa equipe entrega resultados que importam para o seu negócio.\nO que fazemos # Migração para Cloud: Planejamento e execução de migração para AWS, Google Cloud e Azure Segurança e Compliance: Firewall, WAF, SIEM, LGPD e recuperação de desastres DevOps e Automação: CI/CD, Infrastructure as Code, Kubernetes e containers Infraestrutura Gerenciada: Monitoramento 24/7, escalonamento automatico e otimização de custos GLPI: Software livre de gestão de ativos de TI e service desk ITIL com deploy containerizado Por que EF-TECH? # Equipe certificada nas principais plataformas de cloud Foco em performance, segurança e custo-benefício Atendimento personalizado para cada cliente Suporte tecnico dedicado via portal GLPI Entre em contato e descubra como podemos ajudar a transformar sua infraestrutura.\n","date":"17 julho 2026","externalUrl":null,"permalink":"/pt-br/","section":"Soluções em Cloud Computing","summary":"Transforme a performance e a segurança do seu ambiente com nossas soluções!","title":"Soluções em Cloud Computing","type":"pt-br"},{"content":"","date":"17 julho 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"10 julho 2026","externalUrl":null,"permalink":"/tags/ai/","section":"Tags","summary":"","title":"Ai","type":"tags"},{"content":"","date":"10 julho 2026","externalUrl":null,"permalink":"/tags/glpi/","section":"Tags","summary":"","title":"Glpi","type":"tags"},{"content":"","date":"10 julho 2026","externalUrl":null,"permalink":"/tags/ia/","section":"Tags","summary":"","title":"Ia","type":"tags"},{"content":"","date":"10 julho 2026","externalUrl":null,"permalink":"/tags/mcp/","section":"Tags","summary":"","title":"Mcp","type":"tags"},{"content":"EF-TECH is proud to announce mcp-glpi, an open-source server that implements the Model Context Protocol (MCP) to expose the entire GLPI ecosystem to AI assistants such as Claude, Cline, GitHub Copilot, and any other MCP-compatible client.\nWhat is MCP-GLPI? # MCP (Model Context Protocol) is an open standard by Anthropic that allows AI assistants to connect to external systems securely and in a structured way. mcp-glpi is the bridge between this protocol and GLPI — the most widely used open-source IT service management (ITSM) platform.\nWith it, you can ask an AI assistant in natural language:\n\u0026ldquo;List open high-urgency tickets\u0026rdquo; \u0026ldquo;Create a ticket reporting that the database server is at 95% CPU usage\u0026rdquo; \u0026ldquo;Show me João\u0026rsquo;s computer data\u0026rdquo; \u0026ldquo;What is the total asset count in the inventory?\u0026rdquo; \u0026ldquo;Add a follow-up to ticket #42 stating the issue has been resolved\u0026rdquo; All without leaving your favorite AI assistant.\nKey Features # The server exposes 84 MCP tools and 9 resources organized into the following categories:\nTicket Management (Full ITIL) # Area Tools Reading List, get details, timeline, follow-ups, tasks, solutions, validations, documents, satisfaction, overdue tickets (SLA) Writing Create, update, delete, add follow-up, add task with time tracking, add solution, assign ticket, link tickets, request validation, approve/refuse validation, attach document Problems and Changes # List, get, create, and update problems List, get, create, and update changes Asset Management # Computers: list, get (with software, network ports, connections, documents), create, update, and delete Software: list, get, and create Network Equipment: list, get, and create Printers: list, get, and create Monitors: list, get, and create Phones: list, get, and create Knowledge Base, Contracts, Suppliers, and Locations # List, get, and create knowledge base articles (with text search) List, get, and create contracts, suppliers, locations, and projects Users, Groups, and Categories # List users, search by login, create user List and create groups, add user to group List ticket categories List entities Statistics and Introspection # Ticket counts by status (with entity/period filter) Total assets by type Ticket distribution by status, category, technician, entity, or month Searchable field catalog Active session information Resources # Beyond tools, the server exposes resources in the glpi:// format:\nglpi://tickets/open — open tickets glpi://tickets/recent — recent tickets glpi://problems/open — open problems glpi://changes/pending — pending changes glpi://computers — computers glpi://groups — groups glpi://categories — categories glpi://stats/tickets — ticket statistics glpi://stats/assets — asset statistics Technology # mcp-glpi is built with TypeScript and runs on Bun, offering:\nOAuth2 authentication with support for password grant, client_credentials, and bearer token Unified HTTP layer with automatic reauthentication on 401, retry on 5xx/429, and configurable timeouts Multi-criteria search with RSQL filters (AND/OR/AND NOT/OR NOT), pagination, and fetch_all Dynamic field mapping — translations between field_id and names are cached with a 1-hour TTL Resolved foreign keys — details return both the ID and readable name without additional queries Runtime input validation with Zod — clear errors instead of GLPI failures Security annotations — readOnlyHint on query tools, destructiveHint on write/delete operations Docker image based on oven/bun:1-alpine, running as non-root user (bunuser:1001) How to Use # With Claude Desktop / Claude Code # Add to your claude_desktop_config.json:\n{ \u0026#34;mcpServers\u0026#34;: { \u0026#34;glpi\u0026#34;: { \u0026#34;command\u0026#34;: \u0026#34;bunx\u0026#34;, \u0026#34;args\u0026#34;: [\u0026#34;mcp-glpi\u0026#34;], \u0026#34;env\u0026#34;: { \u0026#34;GLPI_URL\u0026#34;: \u0026#34;https://glpi.your-company.com\u0026#34;, \u0026#34;GLPI_AUTH_METHOD\u0026#34;: \u0026#34;password\u0026#34;, \u0026#34;GLPI_USERNAME\u0026#34;: \u0026#34;your_username\u0026#34;, \u0026#34;GLPI_PASSWORD\u0026#34;: \u0026#34;your_password\u0026#34;, \u0026#34;GLPI_CLIENT_ID\u0026#34;: \u0026#34;your_client_id\u0026#34; } } } } With Docker # docker pull ghcr.io/eftechcombr/mcp-glpi:1.0 docker run -i --rm \\ -e GLPI_URL=\u0026#34;https://glpi.your-company.com\u0026#34; \\ -e GLPI_AUTH_METHOD=\u0026#34;password\u0026#34; \\ -e GLPI_USERNAME=\u0026#34;your_username\u0026#34; \\ -e GLPI_PASSWORD=\u0026#34;your_password\u0026#34; \\ -e GLPI_CLIENT_ID=\u0026#34;your_client_id\u0026#34; \\ ghcr.io/eftechcombr/mcp-glpi:1.0 Prerequisites # A GLPI instance (version 10 or 11) with API access An OAuth2 client configured in GLPI (Setup → General → OAuth2 Client) An MCP-compatible AI assistant (Claude, Cline, Continue, etc.) Why We Built This # At EF-TECH, we work with GLPI daily — whether in service desk operations for our clients or developing Docker images and Helm Charts for containerized deployment.\nWe noticed that AI assistants are becoming increasingly present in IT teams\u0026rsquo; daily workflows, yet a direct connection between them and management tools was still missing. mcp-glpi fills exactly that gap: instead of manually copying and pasting information, the AI assistant queries and records data directly in GLPI.\nRoadmap # The server is already functional and in use, but we have several plans for evolution:\nSupport for change approval workflows Custom reporting tools Expanded asset coverage (network devices, batteries, etc.) Integration with more assistants and IDEs Contribute # mcp-glpi is open-source under the MIT license and available on GitHub:\n🔗 https://github.com/eftechcombr/mcp-glpi\nContributions are welcome! Issues, pull requests, and suggestions are open to the community.\nUseful Links # GitHub Repository NPM Package Model Context Protocol GLPI Project GLPI API Documentation At EF-TECH, we specialize in GLPI, cloud computing, and IT infrastructure. We offer expert support for GLPI deployment, maintenance, and integration with modern tools. Contact us to learn how we can help your team.\n","date":"10 julho 2026","externalUrl":null,"permalink":"/en/blog/mcp-glpi/","section":"Cloud Computing Solutions","summary":"EF-TECH launches mcp-glpi, an MCP (Model Context Protocol) server that lets AI assistants interact directly with GLPI through 84 tools and 9 resources, covering tickets, assets, problems, changes, knowledge base, contracts and more.","title":"MCP-GLPI: Integrate AI Assistants with GLPI via Model Context Protocol","type":"en"},{"content":"A EF-TECH tem o prazer de anunciar o mcp-glpi, um servidor open-source que implementa o Model Context Protocol (MCP) para expor todo o ecossistema GLPI a assistentes de IA como Claude, Cline, GitHub Copilot e qualquer outro cliente compatível com MCP.\nO que é o MCP-GLPI? # O MCP (Model Context Protocol) é um protocolo aberto padronizado pela Anthropic que permite que assistentes de IA se conectem a sistemas externos de forma segura e estruturada. O mcp-glpi é a ponte entre esse protocolo e o GLPI — o software livre de gestão de serviços de TI (ITSM) mais utilizado no Brasil.\nCom ele, você pode pedir em linguagem natural para um assistente de IA:\n\u0026ldquo;Liste os tickets abertos de alta urgência\u0026rdquo; \u0026ldquo;Crie um chamado informando que o servidor de banco está com 95% de uso de CPU\u0026rdquo; \u0026ldquo;Mostre os dados do computador do João\u0026rdquo; \u0026ldquo;Qual o total de ativos no inventário?\u0026rdquo; \u0026ldquo;Adicione um acompanhamento no ticket #42 informando que o problema foi resolvido\u0026rdquo; Tudo isso sem sair do seu assistente de IA favorito.\nPrincipais funcionalidades # O servidor expõe 84 ferramentas MCP e 9 recursos organizados nas seguintes categorias:\nGestão de Tickets (ITIL completo) # Área Ferramentas Leitura Listar, obter detalhes, timeline, acompanhamentos, tarefas, soluções, validações, documentos, satisfação, tickets em atraso (SLA) Escrita Criar, atualizar, deletar, adicionar acompanhamento, adicionar tarefa com apontamento de horas, adicionar solução, atribuir ticket, vincular tickets, solicitar validação, aprovar/recusar validação, anexar documento Problemas e Mudanças # Listar, obter, criar e atualizar problemas Listar, obter, criar e atualizar mudanças Gestão de Ativos # Computadores: listar, obter (com software, portas de rede, conexões, documentos), criar, atualizar e deletar Softwares: listar, obter e criar Equipamentos de rede: listar, obter e criar Impressoras: listar, obter e criar Monitores: listar, obter e criar Telefones: listar, obter e criar Base de Conhecimento, Contratos, Fornecedores e Locais # Listar, obter e criar artigos na base de conhecimento (com busca textual) Listar, obter e criar contratos, fornecedores, locais e projetos Usuários, Grupos e Categorias # Listar usuários, buscar por login, criar usuário Listar e criar grupos, adicionar usuário a grupo Listar categorias de tickets Listar entidades Estatísticas e Introspecção # Contagem de tickets por status (com filtro por entidade/período) Totais de ativos por tipo Distribuição de tickets por status, categoria, técnico, entidade ou mês Catálogo de campos pesquisáveis Informações da sessão ativa Recursos (Resources) # Além das ferramentas, o servidor expõe recursos no formato glpi://:\nglpi://tickets/open — tickets abertos glpi://tickets/recent — tickets recentes glpi://problems/open — problemas abertos glpi://changes/pending — mudanças pendentes glpi://computers — computadores glpi://groups — grupos glpi://categories — categorias glpi://stats/tickets — estatísticas de tickets glpi://stats/assets — estatísticas de ativos Tecnologia # O mcp-glpi é construído com TypeScript e executado com Bun, oferecendo:\nAutenticação OAuth2 com suporte a password grant, client_credentials e bearer token Camada HTTP unificada com reautenticação automática em 401, retry em 5xx/429 e timeouts configuráveis Busca multicritério com filtros RSQL (AND/OR/AND NOT/OR NOT), paginação e fetch_all Mapeamento dinâmico de campos — as traduções entre field_id e nome são cacheadas com TTL de 1 hora Chaves estrangeiras resolvidas — detalhes retornam o ID e o nome legível, sem necessidade de consultas adicionais Validação de entrada em runtime com Zod — erros claros em vez de falhas no GLPI Anotações de segurança — readOnlyHint em ferramentas de consulta, destructiveHint em operações de escrita/exclusão Imagem Docker baseada em oven/bun:1-alpine, executando como usuário não-root (bunuser:1001) Como usar # Com Claude Desktop / Claude Code # Adicione ao seu claude_desktop_config.json:\n{ \u0026#34;mcpServers\u0026#34;: { \u0026#34;glpi\u0026#34;: { \u0026#34;command\u0026#34;: \u0026#34;bunx\u0026#34;, \u0026#34;args\u0026#34;: [\u0026#34;mcp-glpi\u0026#34;], \u0026#34;env\u0026#34;: { \u0026#34;GLPI_URL\u0026#34;: \u0026#34;https://glpi.sua-empresa.com\u0026#34;, \u0026#34;GLPI_AUTH_METHOD\u0026#34;: \u0026#34;password\u0026#34;, \u0026#34;GLPI_USERNAME\u0026#34;: \u0026#34;seu_usuario\u0026#34;, \u0026#34;GLPI_PASSWORD\u0026#34;: \u0026#34;sua_senha\u0026#34;, \u0026#34;GLPI_CLIENT_ID\u0026#34;: \u0026#34;seu_client_id\u0026#34; } } } } Com Docker # docker pull ghcr.io/eftechcombr/mcp-glpi:1.0 docker run -i --rm \\ -e GLPI_URL=\u0026#34;https://glpi.sua-empresa.com\u0026#34; \\ -e GLPI_AUTH_METHOD=\u0026#34;password\u0026#34; \\ -e GLPI_USERNAME=\u0026#34;seu_usuario\u0026#34; \\ -e GLPI_PASSWORD=\u0026#34;sua_senha\u0026#34; \\ -e GLPI_CLIENT_ID=\u0026#34;seu_client_id\u0026#34; \\ ghcr.io/eftechcombr/mcp-glpi:1.0 Pré-requisitos # Uma instância do GLPI (versão 10 ou 11) com acesso à API Um cliente OAuth2 configurado no GLPI (Setup → General → OAuth2 Client) Um dos assistentes de IA compatíveis com MCP (Claude, Cline, Continue, etc.) Por que lançamos isso? # Na EF-TECH, trabalhamos diariamente com GLPI — seja na operação de service desk dos nossos clientes, seja no desenvolvimento de imagens Docker e Helm Charts para deploy containerizado.\nPercebemos que os assistentes de IA estão cada vez mais presentes no dia a dia de times de TI, mas ainda falta uma conexão direta entre eles e as ferramentas de gestão. O mcp-glpi preenche exatamente essa lacuna: em vez de copiar e colar informações manualmente, o assistente de IA consulta e registra dados diretamente no GLPI.\nO que vem por aí? # O servidor já está funcional e em uso, mas temos vários planos para evolução:\nSuporte a workflow de aprovação de mudanças Ferramentas para relatórios personalizados Melhorias na cobertura de ativos (dispositivos de rede, baterias, etc.) Integração com mais assistentes e IDEs Contribua # O mcp-glpi é open-source sob licença MIT e está disponível no GitHub:\n🔗 https://github.com/eftechcombr/mcp-glpi\nContribuições são bem-vindas! Issues, pull requests e sugestões estão abertos para a comunidade.\nLinks úteis # Repositório no GitHub Pacote no NPM Model Context Protocol GLPI Project Documentação da API GLPI Na EF-TECH, somos especialistas em GLPI, cloud computing e infraestrutura de TI. Oferecemos suporte especializado para implantação, manutenção e integração do GLPI com ferramentas modernas. Entre em contato para saber como podemos ajudar sua equipe.\n","date":"10 julho 2026","externalUrl":null,"permalink":"/pt-br/blog/mcp-glpi/","section":"Soluções em Cloud Computing","summary":"A EF-TECH lança o mcp-glpi, um servidor MCP (Model Context Protocol) que permite que assistentes de IA interajam diretamente com o GLPI via 84 ferramentas e 9 recursos, cobrindo tickets, ativos, problemas, mudanças, base de conhecimento, contratos e muito mais.","title":"MCP-GLPI: integre assistentes de IA com o GLPI via Model Context Protocol","type":"pt-br"},{"content":"","date":"10 julho 2026","externalUrl":null,"permalink":"/tags/model-context-protocol/","section":"Tags","summary":"","title":"Model-Context-Protocol","type":"tags"},{"content":"","date":"10 julho 2026","externalUrl":null,"permalink":"/tags/open-source/","section":"Tags","summary":"","title":"Open-Source","type":"tags"},{"content":"","date":"10 julho 2026","externalUrl":null,"permalink":"/tags/typescript/","section":"Tags","summary":"","title":"Typescript","type":"tags"},{"content":"","date":"9 julho 2026","externalUrl":null,"permalink":"/tags/api/","section":"Tags","summary":"","title":"Api","type":"tags"},{"content":"","date":"9 julho 2026","externalUrl":null,"permalink":"/categories/architecture/","section":"Categories","summary":"","title":"Architecture","type":"categories"},{"content":"","date":"9 julho 2026","externalUrl":null,"permalink":"/tags/architecture/","section":"Tags","summary":"","title":"Architecture","type":"tags"},{"content":"","date":"9 julho 2026","externalUrl":null,"permalink":"/categories/arquitetura/","section":"Categories","summary":"","title":"Arquitetura","type":"categories"},{"content":"","date":"9 julho 2026","externalUrl":null,"permalink":"/tags/arquitetura/","section":"Tags","summary":"","title":"Arquitetura","type":"tags"},{"content":"","date":"9 julho 2026","externalUrl":null,"permalink":"/tags/desenvolvimento-web/","section":"Tags","summary":"","title":"Desenvolvimento-Web","type":"tags"},{"content":"","date":"9 julho 2026","externalUrl":null,"permalink":"/tags/devops/","section":"Tags","summary":"","title":"Devops","type":"tags"},{"content":"","date":"9 julho 2026","externalUrl":null,"permalink":"/tags/engineering/","section":"Tags","summary":"","title":"Engineering","type":"tags"},{"content":"A IETF publicou oficialmente a RFC 10008, padronizando o método de requisição HTTP QUERY. Esta especificação define uma nova maneira padronizada de executar consultas seguras e idempotentes contendo parâmetros de consulta complexos ou volumosos dentro do corpo da requisição (request body).\nPor anos, desenvolvedores enfrentaram dilemas ao escolher entre GET e POST para endpoints de busca e consulta. A RFC 10008 preenche essa lacuna de maneira nativa, oferecendo uma solução limpa e idiomática para o design de APIs modernas.\nAbaixo, apresentamos uma análise completa do método HTTP QUERY, por que ele é importante e como utilizá-lo.\nO Problema Histórico: GET vs. POST # Tradicionalmente, as APIs web tinham duas opções principais para recuperar dados:\nHTTP GET: Excelente para recuperação de recursos porque é seguro (não altera o estado do servidor) e idempotente (pode ser repetido sem efeitos colaterais). No entanto, os parâmetros do GET precisam ser codificados na URI. Quando uma consulta possui parâmetros complexos (como filtros JSON aninhados, queries SQL brutas ou termos de busca muito longos), a URI pode rapidamente exceder os limites de tamanho (geralmente recomenda-se suporte a pelo menos 8000 octetos, mas as restrições variam em proxies e navegadores). Além disso, URIs são frequentemente gravadas em logs de texto simples, gerando riscos de segurança para dados confidenciais de consulta. HTTP POST: Permite enviar parâmetros no corpo da requisição, contornando limitações de tamanho da URI e riscos de logging. No entanto, o POST não é semanticamente seguro ou idempotente por padrão. Caches, proxies e navegadores não podem repetir automaticamente requisições POST malsucedidas nem podem realizar o cache de seus resultados facilmente. A Solução com o Método QUERY # O método QUERY funciona como uma ponte entre os dois. Assim como no POST, a entrada para a operação de consulta é passada no corpo da requisição (conteúdo da query) e não na URI. E assim como no GET, o método é explicitamente seguro e idempotente, permitindo que recursos como cache e retransmissões automáticas operem de forma nativa.\nComparativo de Propriedades dos Métodos # A tabela abaixo resume como o QUERY se compara ao GET e ao POST (adaptada da especificação oficial da RFC):\nPropriedade GET QUERY POST Seguro (Safe) Sim Sim Potencialmente Não Idempotente Sim Sim Potencialmente Não URI para a Query em si Sim (por definição) Opcional (header Location) Não URI para o Resultado Opcional (Content-Location) Opcional (Content-Location) Opcional (Content-Location) Cacheável Sim Sim Sim, mas apenas para GET/HEAD futuros Corpo da Requisição Sem semântica definida Esperado (segundo regras do recurso) Esperado (segundo regras do recurso) Exemplos Práticos # Vejamos como uma consulta longa é transformada dos antigos formatos GET ou POST para o novo método QUERY.\nO padrão antigo e verboso com GET: # Se os parâmetros forem muito grandes, este formato é ineficiente para processar, corre o risco de ser truncado e expõe informações confidenciais nos logs do servidor:\nGET /feed?q=foo\u0026amp;limit=10\u0026amp;sort=-published\u0026amp;filter=conteudo-de-filtro-aninhado-altamente-especifico HTTP/1.1 Host: example.org O contorno comum com POST: # Embora proteja contra logs e truncamento, intermediários de rede não podem presumir que esta requisição é segura ou idempotente:\nPOST /feed HTTP/1.1 Host: example.org Content-Type: application/x-www-form-urlencoded q=foo\u0026amp;limit=10\u0026amp;sort=-published O novo Método QUERY: # Ao realizar uma requisição QUERY, obtemos o melhor dos dois mundos:\nQUERY /feed HTTP/1.1 Host: example.org Content-Type: application/x-www-form-urlencoded Accept: application/json q=foo\u0026amp;limit=10\u0026amp;sort=-published Resposta: # HTTP/1.1 200 OK Content-Type: application/json [ { \u0026#34;id\u0026#34;: 1, \u0026#34;title\u0026#34;: \u0026#34;Primeiro Resultado\u0026#34; }, { \u0026#34;id\u0026#34;: 2, \u0026#34;title\u0026#34;: \u0026#34;Segundo Resultado\u0026#34; } ] Principais Características Técnicas da RFC 10008 # 1. O Cabeçalho Accept-Query # Os servidores podem anunciar suporte ao método QUERY e quais formatos aceitam através do cabeçalho de resposta Accept-Query. Ele utiliza a sintaxe moderna de \u0026ldquo;Campos Estruturados\u0026rdquo; (Structured Fields):\nAccept-Query: \u0026#34;application/jsonpath\u0026#34;, application/sql;charset=\u0026#34;UTF-8\u0026#34; Os clientes podem descobrir o suporte por meio de uma requisição OPTIONS ou inspecionando o cabeçalho Allow em uma resposta 405 Method Not Allowed:\nOPTIONS /contacts HTTP/1.1 Host: example.org --- Resposta --- HTTP/1.1 200 OK Allow: GET, QUERY, OPTIONS, HEAD 2. Cache e Chaves de Cache (Cache Keys) # Fazer cache de requisições QUERY é inerentemente mais complexo do que fazer cache de requisições GET porque o cache precisa construir uma chave utilizando tanto a URI quanto o corpo da requisição (conteúdo da query), junto aos metadados associados.\nPara melhorar a eficiência, os caches têm permissão para normalizar diferenças pequenas e semanticamente insignificantes nos corpos das requisições (como remover espaços em branco no JSON ou remover codificações de conteúdo específicas) antes de gerar a chave de cache.\n3. Redirecionamento e Recursos Equivalentes # Ao processar um QUERY, o servidor pode atribuir uma URI para a própria definição de consulta ou para o resultado específico dela.\nCampo de resposta Location: Indica uma URI que representa a consulta em si. O cliente pode enviar uma requisição GET padrão para esta URI para repetir a busca sem precisar reenviar o corpo pesado da requisição. Campo de resposta Content-Location: Aponta para um recurso temporário contendo o resultado estático da consulta que acabou de ser realizada. Por exemplo, o servidor pode responder com:\nHTTP/1.1 200 OK Content-Type: application/json Location: /contacts/stored-queries/42 Content-Location: /contacts/stored-results/17 Os clientes podem, subsequentemente, enviar uma requisição GET /contacts/stored-queries/42 para executar a mesma busca de forma simplificada.\nConsiderações de Segurança # A RFC 10008 destaca várias vantagens e requisitos de segurança para os implementadores:\nPrevenção de Vazamento em Logs: Parâmetros de busca sensíveis (como IDs de usuários ou chaves de busca personalizadas) ficam contidos no corpo, evitando a exposição em logs de servidores e proxies em texto claro. URIs de Recursos Temporários: Se o servidor atribuir uma URI para a consulta (utilizando Location ou Content-Location), ele deve garantir que essa nova URI gerada não exponha partes confidenciais do corpo original da requisição. Tratamento de CORS: Navegadores que implementam Compartilhamento de Recursos de Origem Cruzada (CORS) farão uma requisição de \u0026ldquo;preflight\u0026rdquo; (OPTIONS) antes de um QUERY, uma vez que ele não pertence ao grupo de métodos isentos de preflight pelo CORS. Conclusão # A padronização do método QUERY representa um marco importante para a arquitetura RESTful. Ela elimina o abuso semântico do POST para buscas, resolve as limitações de tamanho e vazamentos de segurança do GET, e abre caminhos mais eficientes para otimizações de cache em servidores de API e intermediários de rede.\nÀ medida que os frameworks web e proxies reversos começam a implementar suporte nativo para a RFC 10008, desenvolvedores devem considerar a adoção do QUERY para endpoints de filtragem, buscas complexas e relatórios que exijam grandes payloads.\nPara ler a especificação técnica completa, consulte o padrão oficial:\nRFC 10008: The HTTP QUERY Method Deseja modernizar a arquitetura das suas APIs ou aprimorar a observabilidade dos seus sistemas? Na EF-TECH, ajudamos empresas a desenhar arquiteturas de software escaláveis, eficientes e robustas. Entre em contato.\n","date":"9 julho 2026","externalUrl":null,"permalink":"/pt-br/blog/rfc-10008-http-query/","section":"Soluções em Cloud Computing","summary":"A RFC 10008 padroniza o método HTTP QUERY, preenchendo uma lacuna antiga entre GET e POST. Ele permite requisições seguras e idempotentes com parâmetros no corpo da requisição, resolvendo limites de tamanho de URIs e mantendo os benefícios de cache e retransmissão.","title":"Entendendo a RFC 10008: O Método HTTP QUERY","type":"pt-br"},{"content":"","date":"9 julho 2026","externalUrl":null,"permalink":"/tags/error-budget/","section":"Tags","summary":"","title":"Error-Budget","type":"tags"},{"content":"","date":"9 julho 2026","externalUrl":null,"permalink":"/tags/google/","section":"Tags","summary":"","title":"Google","type":"tags"},{"content":" Google SRE Principles: Evolution from Traditional Operations to Site Reliability Engineering # The Evolution from Traditional Operations to SRE # Traditional operations approaches typically focused on reactive problem-solving and maintenance of IT infrastructure. Organizations would allocate teams primarily for troubleshooting, patch management, and day-to-day system administration. This model often led to a \u0026ldquo;firefighting\u0026rdquo; culture where teams were constantly reacting to incidents rather than proactively improving system reliability.\nGoogle recognized this inefficiency and developed Site Reliability Engineering (SRE) as a way to bridge the gap between software engineering and operations. SRE treats operational work as an engineering problem that can be solved through automation, measurement, and systematic improvement. Instead of having separate \u0026ldquo;operations\u0026rdquo; and \u0026ldquo;development\u0026rdquo; teams, SRE integrates reliability engineering directly into the product development lifecycle.\nThe fundamental shift is viewing reliability as a measurable, engineering-driven discipline rather than an operational afterthought. SRE teams work alongside product teams to ensure that systems are not only reliable but also scalable, efficient, and maintainable at Google\u0026rsquo;s massive scale.\nGoogle SRE Core Principles # The 50% Engineering Rule # Google\u0026rsquo;s SRE teams operate under a strict constraint: SREs can spend no more than 50% of their time on operational work. This creates a powerful feedback loop that encourages teams to build more self-maintaining systems.\nThe rule is enforced by tracking the operational load of each SRE team and reassigning excess tickets to the product development teams that own the services. When operational work exceeds the 50% threshold, SREs work to shift the burden back to the engineering teams that build the services.\nThis principle serves multiple purposes:\nIt prevents SRE teams from becoming bogged down in routine operational tasks It forces product teams to take ownership of reliability It creates incentives to automate repetitive work It promotes a culture of prevention over reaction The 50% rule is not just a time allocation guideline—it\u0026rsquo;s a fundamental philosophy that prioritizes engineering work over operational work.\nError Budget Management # Error budget management is one of the most distinctive aspects of SRE. Instead of aiming for \u0026ldquo;perfect availability,\u0026rdquo; SRE teams set realistic Service Level Objectives (SLOs) and service level agreements (SLAs) that define acceptable levels of service degradation.\nSLOs are internal targets for reliability (e.g., \u0026ldquo;99.9% availability over a 30-day window\u0026rdquo;), while SLAs are contractual commitments to customers (e.g., \u0026ldquo;99.95% availability with 2 hours of maintenance per month\u0026rdquo;). The difference between an SLA and an SLO creates an error budget—the amount of downtime or performance degradation that\u0026rsquo;s acceptable.\nWhen service performance exceeds the SLO, teams have a predetermined error budget they can spend. When that budget is exhausted, teams must pause new features or changes until reliability targets are restored. This approach provides a concrete, quantitative way to balance reliability with business needs.\nThe error budget concept transforms reliability from a binary \u0026ldquo;working\u0026rdquo; or \u0026ldquo;broken\u0026rdquo; state into a continuous optimization problem where teams can make informed decisions about risk vs. reward.\nMonitoring Approach (Alerts, Tickets, Logs) # Google SRE\u0026rsquo;s monitoring approach is comprehensive and data-driven, focusing on three key data sources:\nAlerts # SREs use proactive monitoring to detect potential issues before they become incidents. Google\u0026rsquo;s alerting systems are carefully tuned to avoid alert fatigue—alerts are only sent when there\u0026rsquo;s a genuine need for attention. The philosophy is \u0026ldquo;only alert on what you can fix automatically.\u0026rdquo;\nAlerts are categorized by severity:\nPage alerts: Critical issues requiring immediate attention Ticket alerts: Important but less urgent issues logged as tickets Log-based alerts: Issues detected through pattern analysis in logs The emphasis is on creating alerts that are both useful and actionable, with clear runbooks and escalation paths.\nTickets # Tickets in SRE are used for issues that cannot be resolved automatically or require investigation. Unlike traditional ticket systems where most work goes in, SRE ticket systems are designed to route work to the appropriate teams and track operational load against the 50% constraint.\nTickets are prioritized based on business impact and customer effects, with clear criteria for determining urgency and assignment.\nLogs # Comprehensive logging is essential for SRE. Google collects logs at multiple levels:\nApplication logs System logs Infrastructure logs Logs are analyzed for pattern recognition, anomaly detection, and forensic analysis. The goal is to have enough context to understand what happened, when, and why—enough to prevent future incidents.\nThe SRE monitoring philosophy emphasizes \u0026ldquo;as much monitoring as needed, but no more,\u0026rdquo; with a strong focus on reducing noise and increasing signal quality.\nChange Management with Progressive Rollouts # Traditional change management often involves big, coordinated deployments that can introduce significant risk. Google SRE adopts a different approach through progressive rollouts.\nProgressive rollouts involve slowly introducing changes to a small percentage of users or infrastructure, monitoring for issues, and gradually increasing the rollout until the change reaches 100% of users. This approach allows teams to catch problems early and limit the blast radius of failed changes.\nThe process typically involves:\nCanary releases: Deploying to a small subset of servers Gradual expansion: Monitoring and increasing the percentage Automated rollback: Immediate rollback on detected issues Metrics monitoring: Using real-world performance data to guide rollout speed This approach transforms change management from a risk-averse process to a risk-managed one, allowing teams to move quickly while maintaining reliability.\nEmergency Response with Playbooks # When incidents do occur, SRE teams follow structured playbooks that provide clear, step-by-step guidance for resolution. These playbooks are critical for ensuring consistent, effective response under pressure.\nGoogle SRE playbooks include:\nIncident response playbooks: Step-by-step guides for common incident types Post-incident review processes: Systematic analysis of what happened and why Communication templates: Clear messaging for internal and external stakeholders Root cause analysis frameworks: Structured approaches to understanding incident causes The emergency response process emphasizes:\nSpeed: Quick identification and containment of issues Clarity: Clear roles and responsibilities Documentation: Detailed logging of actions and decisions Learning: Extracting insights for future prevention Playbooks are continuously refined based on real-world experience, creating an evolving knowledge base of incident response best practices.\nKey Insights About What Makes SRE Different # SRE isn\u0026rsquo;t just a set of practices—it\u0026rsquo;s a cultural shift that transforms how organizations think about reliability and operations:\n1. Engineering Mindset # SRE applies software engineering disciplines to operations problems. Instead of \u0026ldquo;fixing\u0026rdquo; systems, SRE engineers \u0026ldquo;design\u0026rdquo; reliable systems from the ground up.\n2. Measured Approach # Everything in SRE is measured and quantified. From error budgets to service level objectives, decisions are based on data rather than opinions.\n3. Automation as Enabler # Automation is not the end goal but rather an enabler that frees up time for higher-value engineering work. SREs automate everything that\u0026rsquo;s repetitive, predictable, and boring.\n4. Shared Responsibility # Reliability is not the sole responsibility of an operations team. Product teams, engineering teams, and SRE teams all share responsibility for service reliability.\n5. Continuous Improvement # SRE embraces the idea that there\u0026rsquo;s always room for improvement. Teams regularly analyze their performance against SLOs, identify areas for improvement, and work to eliminate toil.\n6. Risk-Aware Decisions # SRE teams make conscious decisions about risk vs. reward, balancing business needs with reliability requirements. This includes calculated decisions about when to launch new features vs. invest in reliability improvements.\n7. Customer-Centric Focus # All SRE decisions ultimately consider the impact on customers. Whether it\u0026rsquo;s setting SLOs, prioritizing work, or making trade-offs, the customer experience is the north star.\nConclusion # Google SRE principles represent a fundamental rethinking of how organizations approach reliability and operations. By treating operational work as an engineering problem, focusing on measurement and automation, and empowering teams to take ownership of reliability, SRE creates a more efficient, reliable, and innovative approach to running complex systems.\nThe success of SRE at Google demonstrates that reliability and rapid innovation are not mutually exclusive—through careful engineering, measurement, and cultural change, organizations can achieve both. The principles outlined in Google\u0026rsquo;s SRE Book continue to influence how technology companies approach reliability worldwide.\n","date":"9 julho 2026","externalUrl":null,"permalink":"/en/blog/google-sre-principles/","section":"Cloud Computing Solutions","summary":"","title":"Google SRE Principles: Evolution from Traditional Operations to Site Reliability Engineering","type":"en"},{"content":"","date":"9 julho 2026","externalUrl":null,"permalink":"/tags/http/","section":"Tags","summary":"","title":"Http","type":"tags"},{"content":"","date":"9 julho 2026","externalUrl":null,"permalink":"/tags/operations/","section":"Tags","summary":"","title":"Operations","type":"tags"},{"content":" Princípios SRE do Google: Evolução da Operações Tradicionais para a Engenharia de Confiabilidade de Sites # A Evolução das Operações Tradicionais para o SRE # As abordagens tradicionais de operações geralmente se concentravam na resolução reativa de problemas e na manutenção da infraestrutura de TI. As organizações alocavam equipes principalmente para solução de problemas, gerenciamento de patches e administração diária de sistemas. Este modelo muitas vezes levava a uma cultura de \u0026ldquo;combate a incêndios\u0026rdquo;, onde as equipes estavam constantemente reagindo a incidentes em vez de melhorar proativamente a confiabilidade.\nO Google reconheceu esta ineficiência e desenvolveu o Site Reliability Engineering (SRE) como uma forma de aproximar a engenharia de software e as operações. O SRE trata o trabalho operacional como um problema de engenharia que pode ser resolvido através da automação, medição e melhoria sistemática. Em vez de ter equipes separadas de \u0026ldquo;operações\u0026rdquo; e \u0026ldquo;desenvolvimento\u0026rdquo;, o SRE integra a engenharia de confiabilidade diretamente no ciclo de vida do desenvolvimento de produtos.\nA mudança fundamental é ver a confiabilidade como uma disciplina orientada por engenharia e mensurável, em vez de uma consideração posterior para as operações. As equipes SRE trabalham ao lado das equipes de produtos para garantir que os sistemas sejam não apenas confiáveis, mas também escaláveis, eficientes e sustentáveis na escala massiva do Google.\nPrincípios Fundamentais do SRE do Google # A Regra dos 50% de Engenharia # As equipes SRE do Google operam sob uma restrição rigorosa: os SREs podem gastar no máximo 50% do seu tempo em trabalho operacional. Isso cria um poderoso ciclo de feedback que incentiva as equipes a construírem sistemas mais autossustentáveis.\nA regra é aplicada monitorando a carga operacional de cada equipe SRE e reatribuindo tarefas excedentes às equipes de desenvolvimento de produtos que possuem os serviços. Quando o trabalho operacional excede o limite de 50%, os SREs trabalham para transferirem o ônus de volta às equipes de engenharia que construíram os serviços.\nEste princípio serve múltiplos propósitos:\nImpede que as equipes SRE fiquem sobrecarregadas com tarefas operacionais rotineiras Força as equipes de produtos a assumirem a responsabilidade pela confiabilidade Cria incentivos para automatizar tarefas repetitivas Promove uma cultura de prevenção em vez de reação A regra de 50% não é apenas uma diretriz de alocação de tempo - é uma filosofia fundamental que prioriza o trabalho de engenharia sobre o trabalho operacional.\nGerenciamento de Orçamento de Erros # O gerenciamento de orçamento de erros é um dos aspectos mais distintos do SRE. Em vez de buscar \u0026ldquo;disponibilidade perfeita\u0026rdquo;, as equipes SRE definem objetivos de nível de serviço (SLOs) e acordos de nível de serviço (SLAs) realistas que definem níveis aceitáveis de degradação de serviço.\nSLOs são metas internas de confiabilidade (por exemplo, \u0026ldquo;99,9% de disponibilidade em um período de 30 dias\u0026rdquo;), enquanto SLAs são compromissos contratuais com os clientes (por exemplo, \u0026ldquo;99,95% de disponibilidade com 2 horas de manutenção por mês\u0026rdquo;). A diferença entre um SLA e um SLO cria um orçamento de erro - a quantidade de tempo de inatividade ou degradação de desempenho que é aceitável.\nQuando o desempenho do serviço excede o SLO, as equipes têm um orçamento de erro predefinido que podem gastar. Quando esse orçamento é esgotado, as equipes devem pausar novas funcionalidades ou alterações até que as metas de confiabilidade sejam restauradas. Esta abordagem fornece uma forma concreta e quantitativa de equilibrar confiabilidade com necessidades de negócios.\nO conceito de orçamento de erro transforma a confiabilidade de um estado binário de \u0026ldquo;funcionando\u0026rdquo; ou \u0026ldquo;quebrado\u0026rdquo; em um problema contínuo de otimização onde as equipes podem tomar decisões informadas sobre risco versus recompensa.\nAbordagem de Monitoramento (Alertas, Tickets, Logs) # A abordagem de monitoramento do Google SRE é abrangente e orientada por dados, focando em três fontes de dados-chave:\nAlertas # Os SREs usam monitoramento proativo para detectar problemas potenciais antes que se tornem incidentes. Os sistemas de alerta do Google são cuidadosamente ajustados para evitar fadiga de alertas - os alertas são enviados apenas quando há uma necessidade genuína de atenção. A filosofia é \u0026ldquo;somente alertar sobre o que você pode consertar automaticamente.\u0026rdquo;\nOs alertas são categorizados por gravidade:\nAlertas de página: Problemas críticos que requerem atenção imediata Alertas de ticket: Problemas importantes mas menos urgentes registrados como tickets Alertas baseados em logs: Problemas detectados através de análise de padrões em logs A ênfase está em criar alertas que sejam tanto úteis quanto acionáveis, com runbooks e caminhos de escalação claros.\nTickets # Os tickets no SRE são usados para problemas que não podem ser resolvidos automaticamente ou requerem investigação. Diferente dos sistemas de ticket tradicionais onde a maioria do trabalho entra, os sistemas de ticket do SRE são projetados para rotear o trabalho às equipes apropriadas e monitorar a carga operacional contra a restrição de 50%.\nOs tickets são priorizados com base no impacto nos negócios e nos efeitos sobre os clientes, com critérios claros para determinar urgência e atribuição.\nLogs # O registro abrangente é essencial para o SRE. O Google coleta logs em múltiplos níveis:\nLogs de aplicação Logs de sistema Logs de infraestrutura Os logs são analisados para reconhecimento de padrões, detecção de anomalias e análise forense. O objetivo é ter contexto suficiente para entender o que aconteceu, quando e porquê - suficiente para prevenir incidentes futuros.\nA filosofia de monitoramento do SRE enfatiza \u0026ldquo;o quanto de monitoramento for necessário, mas não mais que isso\u0026rdquo;, com um forte foco em reduzir ruído e aumentar a qualidade do sinal.\nGestão de Mudanças com Implementações Progressivas # A gestão de mudanças tradicionalmente envolve grandes implementações coordenadas que podem introduzir riscos significativos. O Google SRE adota uma abordagem diferente através de implementações progressivas.\nAs implementações progressivas envolvem a introdução lenta de mudanças para um pequeno percentual de usuários ou infraestrutura, monitorando problemas e aumentando gradualmente a implementação até que a mudança atinja 100% dos usuários. Esta abordagem permite que as equipes detectem problemas precocemente e limitem o raio de explosão de mudanças falhadas.\nO processo tipicamente envolve:\nReleases de canary: implementando para um pequeno subconjunto de servidores Expansão gradual: monitorando e aumentando o percentual Rollback automático: rollback imediato em problemas detectados Monitoramento de métricas: usando dados de performance em tempo real para guiar a velocidade de implementação Esta abordagem transforma a gestão de mudanças de um processo averso ao risco para um processo de gestão de risco, permitindo que as equipes avancem rapidamente enquanto mantêm a confiabilidade.\nResposta a Emergências com Playbooks # Quando incidentes ocorrem, as equipes SRE seguem playbooks estruturados que fornecem orientações passo a passo para resolução. Estes playbooks são críticos para garantir resposta consistente e eficaz sob pressão.\nOs playbooks do Google SRE incluem:\nPlaybooks de resposta a incidentes: guias passo a passo para tipos comuns de incidentes Processos de revisão pós-incidente: análise sistemática do que aconteceu e porquê Modelos de comunicação: mensagens claras para partes interessadas internas e externas Métodos de análise de causa raiz: abordagens estruturadas para entender as causas dos incidentes O processo de resposta a emergências enfatiza:\nVelocidade: rápida identificação e contenção de problemas Clareza: papéis e responsabilidades claros Documentação: registro detalhado de ações e decisões Aprendizado: extração de insights para prevenção futura Os playbooks são continuamente refinados baseados em experiência em tempo real, criando um conhecimento em evolução de melhores práticas de resposta a incidentes.\nPrincipais Insights sobre o que Torna o SRE Diferente # O SRE não é apenas um conjunto de práticas - é uma mudança cultural que transforma como as organizações pensam sobre confiabilidade e operações:\n1. Mentalidade de Engenharia # O SRE aplica disciplinas de engenharia de software a problemas de infraestrutura e operações. Em vez de \u0026ldquo;consertar\u0026rdquo; sistemas, os engenheiros SRE \u0026ldquo;projetam\u0026rdquo; sistemas confiáveis desde o início.\n2. Abordagem Mensurada # Tudo no SRE é medido e quantificado. De orçamentos de erro a objetivos de nível de serviço, as decisões são baseadas em dados e não em opiniões.\n3. Automação como Facilitadora # A automação não é o objetivo final, mas sim um facilitador que libera tempo para trabalho de engenharia de maior valor. Os SREs automatizam tudo o que é repetitivo, previsível e entediante.\n4. Responsabilidade Compartilhada # A confiabilidade não é responsabilidade exclusiva de uma equipe de operações. Equipes de produtos, equipes de engenharia e equipes SRE compartilham a responsabilidade pela confiabilidade do serviço.\n5. Melhoria Contínua # O SRE abraça a ideia de que sempre há espaço para melhoria. As equipes regularmente analisam seu desempenho contra SLOs, identificam áreas para melhoria e trabalham para eliminar o trabalho tedioso.\n6. Decisões Conscientes sobre Riscos # As equipes SRE tomam decisões conscientes sobre risco versus recompensa, balanceando necessidades de negócios com requisitos de confiabilidade. Isso inclui decisões calculadas sobre quando lançar novas funcionalidades versus investir em melhorias de confiabilidade.\n7. Foco no Cliente # Todas as decisões do SRE finalmente consideram o impacto nos clientes. Seja definindo SLOs, priorizando trabalho ou fazendo trade-offs, a experiência do cliente é a estrela norte.\nConclusão # Os princípios SRE do Google representam uma reconsideração fundamental de como as organizações abordam confiabilidade e operações. Ao tratar o trabalho operacional como um problema de engenharia, focar na medição e automação, e capacitar as equipes a assumirem a responsabilidade pela confiabilidade, o SRE cria uma abordagem mais eficiente, confiável e inovadora para administrar sistemas complexos.\nO sucesso do SRE no Google demonstra que confiabilidade e inovação rápida não são mutuamente exclusivas - através de engenharia cuidadosa, medição e mudança cultural, as organizações podem alcançar ambas. Os princípios descritos no Livro SRE do Google continuam a influenciar como as empresas de tecnologia abordam confiabilidade em todo o mundo.\n","date":"9 julho 2026","externalUrl":null,"permalink":"/pt-br/blog/google-sre-principles/","section":"Soluções em Cloud Computing","summary":"","title":"Princípios SRE do Google: Evolução da Operações Tradicionais para a Engenharia de Confiabilidade de Sites","type":"pt-br"},{"content":"","date":"9 julho 2026","externalUrl":null,"permalink":"/tags/progressive-rollout/","section":"Tags","summary":"","title":"Progressive-Rollout","type":"tags"},{"content":"","date":"9 julho 2026","externalUrl":null,"permalink":"/tags/rfc/","section":"Tags","summary":"","title":"Rfc","type":"tags"},{"content":"","date":"9 julho 2026","externalUrl":null,"permalink":"/tags/site-reliability-engineering/","section":"Tags","summary":"","title":"Site-Reliability-Engineering","type":"tags"},{"content":"","date":"9 julho 2026","externalUrl":null,"permalink":"/tags/sre/","section":"Tags","summary":"","title":"Sre","type":"tags"},{"content":"The IETF has officially published RFC 10008, standardizing the HTTP QUERY request method. This specification defines a new, standardized way to execute safe and idempotent queries carrying complex or voluminous query parameters within the request body.\nFor years, developers have struggled with the trade-offs of using GET versus POST for search and query endpoints. RFC 10008 fills this gap, offering a clean, idiomatic solution for modern API design.\nHere is a comprehensive breakdown of the HTTP QUERY method, why it matters, and how to use it.\nThe Core Problem: GET vs. POST # Historically, web APIs had two primary options for retrieving data:\nHTTP GET: Excellent for retrieving resources because it is safe (does not change server state) and idempotent (can be repeated without side effects). However, GET parameters must be encoded in the URI. If a query has complex parameters (e.g., deep JSON filters, raw SQL, or long search terms), the URI can quickly exceed size limits (usually recommended to be at least 8000 octets, but limits vary across proxies and browsers). Furthermore, URIs are frequently logged in plain text, presenting a security risk for sensitive query data. HTTP POST: Allows parameters to be sent in the request body, bypassing URI length limits and logging risks. However, POST is not semantically safe or idempotent by default. Caches, proxies, and web browsers cannot automatically retry failed POST requests, nor can they cache the results easily. The QUERY Method Compromise # The QUERY method acts as a bridge. Like POST, the input to the operation is passed in the request body (the query content) rather than in the URI. Like GET, the method is explicitly safe and idempotent, allowing features like caching and automatic retries to operate out-of-the-box.\nMethod Property Comparison # The table below summaries how QUERY compares to GET and POST (adapted from the RFC specification):\nProperty GET QUERY POST Safe Yes Yes Potentially No Idempotent Yes Yes Potentially No URI for Query Itself Yes (by definition) Optional (Location header) No URI for Query Result Optional (Content-Location) Optional (Content-Location) Optional (Content-Location) Cacheable Yes Yes Yes, but only for future GET/HEAD Request Body No defined semantics Expected (per resource rules) Expected (per resource rules) Examples in Action # Let’s look at how a typical verbose query is transformed from GET or POST to the new QUERY method.\nThe old, verbose GET pattern: # If the parameters are too large, this is inefficient to parse, risks being truncated, and exposes data in server logs:\nGET /feed?q=foo\u0026amp;limit=10\u0026amp;sort=-published\u0026amp;filter=highly-specific-nested-filter-content HTTP/1.1 Host: example.org The old POST workaround: # While safe from logging and truncation, intermediaries cannot assume this request is safe or idempotent:\nPOST /feed HTTP/1.1 Host: example.org Content-Type: application/x-www-form-urlencoded q=foo\u0026amp;limit=10\u0026amp;sort=-published The new QUERY Method: # By sending a QUERY request, we get the best of both worlds:\nQUERY /feed HTTP/1.1 Host: example.org Content-Type: application/x-www-form-urlencoded Accept: application/json q=foo\u0026amp;limit=10\u0026amp;sort=-published Response: # HTTP/1.1 200 OK Content-Type: application/json [ { \u0026#34;id\u0026#34;: 1, \u0026#34;title\u0026#34;: \u0026#34;First Match\u0026#34; }, { \u0026#34;id\u0026#34;: 2, \u0026#34;title\u0026#34;: \u0026#34;Second Match\u0026#34; } ] Key Technical Features of RFC 10008 # 1. The Accept-Query Header Field # Servers can advertise their support for QUERY and the formats they accept using the Accept-Query response header. It uses the modern \u0026ldquo;Structured Fields\u0026rdquo; syntax:\nAccept-Query: \u0026#34;application/jsonpath\u0026#34;, application/sql;charset=\u0026#34;UTF-8\u0026#34; Clients can discover support through an OPTIONS request or by inspecting the Allow header in a 405 Method Not Allowed response:\nOPTIONS /contacts HTTP/1.1 Host: example.org --- Response --- HTTP/1.1 200 OK Allow: GET, QUERY, OPTIONS, HEAD 2. Caching \u0026amp; Caching Keys # Caching QUERY requests is inherently more complex than caching GET requests because the cache must compute a key using both the URI and the request body (the query content) along with relevant metadata.\nTo optimize caching, caches are permitted to normalize minor, semantically insignificant differences in request bodies (such as stripping content encoding or JSON whitespace normalization) before generating the cache key.\n3. Redirection \u0026amp; Equivalent Resources # When executing a QUERY, the server can assign a URI to either the query definition itself or the specific query result.\nLocation response field: Indicates a URI representing the query itself. A client can perform a standard GET request on this URI to repeat the query without resending the heavy body payload. Content-Location response field: Points to a temporary resource containing the static result of the query just executed. For instance, the server might respond with:\nHTTP/1.1 200 OK Content-Type: application/json Location: /contacts/stored-queries/42 Content-Location: /contacts/stored-results/17 Clients can subsequently execute a GET /contacts/stored-queries/42 request to run the same query again.\nSecurity Considerations # RFC 10008 highlights several safety advantages and implementation requirements:\nLogging Avoidance: Query parameters are enclosed in the body, mitigating the risk of exposing sensitive data (like user IDs or custom search terms) in plain-text server and proxy logs. Temporary Resource URIs: If a server assigns a URI to a query (using Location or Content-Location), it must ensure that the newly created URI itself does not contain sensitive parts of the original request body in plain text. CORS Handling: Browsers implementing Cross-Origin Resource Sharing (CORS) will trigger a \u0026ldquo;preflight\u0026rdquo; options request for QUERY because it is not in the CORS-safelisted method group. Conclusion \u0026amp; Further Reading # The standardization of the QUERY method represents a significant milestone in RESTful architecture. It cleans up the semantic abuse of POST for searching, resolves the size constraints and security leaks of GET, and opens up better optimization avenues for API servers and caches alike.\nAs web frameworks and reverse proxies begin implementing native support for RFC 10008, developers should consider adopting QUERY for all search, filter, and reporting endpoints carrying non-trivial query payloads.\nTo read the complete technical specification, check the official standard:\nRFC 10008: The HTTP QUERY Method Are you looking to modernize your API architecture or improve observability across your systems? At EF-TECH, we help organizations design scalable, efficient, and robust software architectures. Contact us.\n","date":"9 julho 2026","externalUrl":null,"permalink":"/en/blog/rfc-10008-http-query/","section":"Cloud Computing Solutions","summary":"RFC 10008 standardizes the HTTP QUERY method, filling the long-standing gap between GET and POST. It enables safe, idempotent requests that carry parameters in the request body, solving URI length limits while retaining caching and retry benefits.","title":"Understanding RFC 10008: The HTTP QUERY Method","type":"en"},{"content":" Understanding Site Reliability Engineering # The Evolution from Operations to Site Reliability Engineering # [SRE is] what happens when you ask a software engineer to design an operations team. — Benjamin Treynor Sloss\nSite Reliability Engineering represents a fundamental shift in how organizations approach system reliability. Rather than separating operations from development, SRE blends them into a cohesive engineering discipline focused on creating systems that run themselves.\n\u0026quot;[Traditional ops teams] often resort to a familiar form of trench warfare to advance their interests.\u0026quot; — SRE Book Introduction\nTraditional Operations vs SRE # Traditional Operations approach:\nReactive maintenance with human intervention Growing operational team scales linearly with service complexity Separate \u0026ldquo;dev\u0026rdquo; and \u0026ldquo;ops\u0026rdquo; teams with conflicting incentives Site Reliability Engineering approach:\nProactive engineering that prevents issues before they occur Automated systems scale with the service Unified team focused on service ownership from development to production Google SRE Core Principles # The 50% Engineering Rule # Google\u0026rsquo;s SRE philosophy centers around one critical principle: SRE teams must dedicate at least 50% of their time to engineering work. This is enforced through quarterly service reviews that monitor operational overhead and trigger corrective actions when the threshold is exceeded.\n\u0026quot;[We] cannot code or it will drown. Therefore, Google places a 50% cap on the aggregate \u0026lsquo;ops\u0026rsquo; work.\u0026quot; — SRE Book\nThis 50/25/25 split ensures SRE remains an engineering function rather than becoming operational support:\n50% development time (feature work, automation, innovation) 25% on-call duties 25% other operational tasks Error Budget Management # The error budget is a revolutionary approach to balancing feature velocity with reliability:\nError Budget = 1 - Availability Target For a service targeting 99.99% availability:\nError Budget = 1 - 0.9999 = 0.0001 (0.01% acceptable unavailability) \u0026ldquo;SRE brings the conflict between innovation pace and stability to the fore, and then resolves it with the introduction of an error budget.\u0026rdquo; — SRE Book\nError Budget Example Code # # Error budget management utility def can_launch_feature(current_error_rate, error_budget, feature_impact=1.0): \u0026#34;\u0026#34;\u0026#34;Determine if a feature can launch based on error budget consumption\u0026#34;\u0026#34;\u0026#34; remaining_budget = error_budget - current_error_rate return remaining_budget * feature_impact \u0026gt; 0 # Usage availability_target = 0.99997 # 99.997% error_budget = 1 - availability_target # Can launch if feature impact \u0026lt; 50% of remaining budget if can_launch_feature(current_error_rate=0.0002, error_budget=error_budget, feature_impact=0.5): release_feature({\u0026#34;urgent\u0026#34;: True}) SRE Monitoring Approach # SRE recognizes that human interpretation of alerts is inherently flawed and scales poorly:\n\u0026ldquo;A system that requires a human to read an email and decide whether or not some type of action needs to be taken is fundamentally flawed.\u0026rdquo; — SRE Book\nThree Valid Output Types # Alerts (immediate human action)\nPage SREs immediately when service health degrades Requires rapid human response to prevent customer impact Tickets (planned human action)\nNotify when action is needed but not urgent Give time for thoughtful planning and execution Logs (diagnostic purposes only)\nMachine-readable records for forensic analysis Humans should trigger log review, not read them directly Example Monitoring Logic # If HTTP status code in (500, 599) AND the log contains \u0026#39;SERVER ERROR\u0026#39; AND DEBUG cookie not set AND URL not \u0026#39;/reports\u0026#39; AND exception not contains \u0026#39;com.google.ads.PasswordException\u0026#39; THEN increment error counter Change Management with Progressive Rollouts # SRE treats changes as experiments rather than big-bang deployments:\nCanary releases: Small-scale deployments to controlled subsets Gradual traffic shifting: Monitor impact before full rollout Automated rollback: Immediate reversion on detected issues A/B testing: Compare new vs old system behavior Progressive Rollout Example # # Progressive rollout configuration rollout: strategy: \u0026#34;gradual\u0026#34; stages: - traffic: 1% # Initial canary duration: 24h - traffic: 5% # Gradual increase duration: 48h - traffic: 100% # Full rollout rollback_threshold: \u0026#34;error_rate \u0026gt; 0.1%\u0026#34; Emergency Response with Playbooks # SRE prepared operations:\nPre-defined procedures: Playbooks for common incident scenarios 3x improvement: Compared to \u0026ldquo;winging it,\u0026rdquo; playbooks significantly reduce MTTR Blame-free culture: Focus on system fixes, not human blame Example Prestashop Playbook Structure # alert: severity: \u0026#34;critical\u0026#34; window: \u0026#34;5 minutes\u0026#34; steps: - action: \u0026#34;Check primary service status\u0026#34; timeout: 30s manual_fallback: true - action: \u0026#34;Query health endpoints\u0026#34; timeout: 60s validate: \u0026#34;response_time \u0026lt; 500ms\u0026#34; - action: \u0026#34;Analyze logs and trigger investigation\u0026#34; trigger: \u0026#34;multi_error_threshold\u0026#34; follow_up: \u0026#34;postmortemma_required\u0026#34; Key SRE Differentiation Factors # Engineering Mindset # Reliability as a feature: Built into the product, not bolted on Measured risk: Quantitative targets (SLOs, error budgets) over qualitative judgments Automation focus: Systematic elimination of repetitive tasks Organizational Structure # Cross-functional teams: Developers who also operate Shared ownership: Product development and SRE teams aligned Career mobility: Easy transfer between dev and SRE improves skills across organization Practical SRE Implementation # Service-Level Objectives (SLOs) # SLOs define reliability targets for individual services:\nAvailability: % of requests served successfully Latency: Target response times Error rate: Acceptable percentage of failed requests Throughput: Service capacity limits Example SLO Definition # services: authentication-api: slo_target: availability: 99.95% # 4.32 minute monthly budget latency_p95: 200ms # 95th percentile response time error_rate: 0.01% # 1 error per 10,000 requests error_budget: computation: \u0026#34;1 - 0.9995 = 0.0005\u0026#34; monthly_budget: \u0026#34;43200 errors allowed\u0026#34; Benefits of SRE # Operational Benefits # Sublinear scaling: SREs needed scale with system complexity, not traffic Innovation velocity: Error budgets enable faster feature launches Cost efficiency: Dedicated teams reduce overall operational overhead Cultural Benefits # Reduced dysfunction: Eliminates dev/ops conflict and silo mentality Cross-training: Engineers develop full-stack skills Continuous learning: SRE teams constantly improving through operational challenges Conclusion # Google\u0026rsquo;s Site Reliability Engineering transforms operations from a cost center into an engineering discipline that drives innovation. By:\nPutting engineering first through the 50% rule Measuring risk through error budgets and SLOs Automating responses through sophisticated monitoring Learning from failures through blameless postmortems SRE creates systems that not only run reliably but also evolve rapidly while maintaining user trust.\n[SRE] represents a significant break from existing industry best practices for managing large, complicated services. — SRE Book\nKey Takeaways # Speed vs. Stability: Error budgets enable rapid innovation while maintaining reliability targets Automation first: Humans should interpret problems, not be the bottleneck Engineering culture: Reliability is everyone\u0026rsquo;s responsibility, not just operations Measured improvement: Quantitative targets drive better decision-making Source: Based on \u0026ldquo;Chapter 1 - Introduction\u0026rdquo; from Google\u0026rsquo;s Site Reliability Engineering Book\nAuthor: Benjamin Treynor Sloss\nLicense: CC BY-NC-ND 4.0\nFor questions about implementing SRE principles in your organization, contact us at EF-TECH.\n","date":"9 julho 2026","externalUrl":null,"permalink":"/en/blog/understanding-sre-google-sre-philosophy-practices/","section":"Cloud Computing Solutions","summary":"Deep dive into Google SRE principles: error budgets, 50% engineering rule, progressive rollouts, and how SRE transforms operations into engineering to balance speed and stability.","title":"Understanding Site Reliability Engineering: Google's SRE Philosophy and Practices","type":"en"},{"content":"","date":"9 julho 2026","externalUrl":null,"permalink":"/tags/web-development/","section":"Tags","summary":"","title":"Web-Development","type":"tags"},{"content":"","date":"26 junho 2026","externalUrl":null,"permalink":"/tags/grafana/","section":"Tags","summary":"","title":"Grafana","type":"tags"},{"content":"A Grafana Labs lançou a versão 13.1, dando continuidade ao ciclo iniciado com a Grafana 13, que trouxe o Git Sync como funcionalidade estável e disponível para todos. Esta versão é particularmente relevante para equipes que adotam observability as code, dependem de dashboards dinâmicos com múltiplos serviços ou precisam conectar fontes de dados on-premise de forma segura.\nA seguir, um resumo das principais novidades organizadas por área de interesse.\nGit Sync: Observability as Code amadurece # O Git Sync, que atingiu GA (disponibilidade geral) na versão 13, continua recebendo melhorias importantes na 13.1. Para quem gerencia dashboards como código, esta é a funcionalidade central da release.\nImportação de dashboards em pastas provisionadas (GA) # Agora é possível importar dashboards diretamente para pastas gerenciadas por provisionamento. Na prática, isso significa que você pode definir a estrutura de pastas via arquivos de configuração e ter os dashboards sincronizados do Git já no local correto, sem intervenção manual.\nSincronização no nível raiz (GA) # O suporte a sincronização a partir da raiz do repositório elimina a necessidade de estruturas de diretório específicas. Basta configurar o caminho desejado e o Grafana interpreta a organização natural do seu repositório.\nREADME.md em pastas Git Sync (public preview) # Pastas sincronizadas via Git Sync agora exibem o arquivo README.md do repositório diretamente no Grafana. Isso facilita a documentação in-line de cada conjunto de dashboards, especialmente em equipes que mantêm múltiplos repositórios de observabilidade.\nCommits assinados com GPG, SSH e S/MIME (GA) # Toda alteração feita via Git Sync pode ser assinada digitalmente, garantindo rastreabilidade e conformidade. O suporte cobre GPG, SSH e S/MIME, atendendo desde times pequenos até ambientes corporativos com políticas rigorosas de auditoria.\nIntegração com GitHub App, GitLab, BitBucket # O Git Sync suporta autenticação via GitHub App (recomendado para organizações que usam GitHub), além de GitLab e BitBucket, e também conexão pura via Git. Isso cobre a maioria dos cenários de mercado.\nGrafana Assistant ganha 8 novos data sources # O assistente baseado em IA do Grafana, que ajuda na criação de queries e interpretação de métricas, foi expandido para suportar oito novas fontes de dados:\nSnowflake — data warehouse na nuvem Oracle — banco de dados relacional corporativo Elasticsearch — busca e análise de logs Dynatrace — monitoramento de performance de aplicações Honeycomb — observabilidade orientada a eventos Zabbix — monitoramento de infraestrutura open source Jira — gerenciamento de projetos e tickets MongoDB — banco NoSQL Disponibilidade # O Grafana Assistant vem pré-instalado no Grafana Enterprise (não requer plugin adicional). Para usuários da versão OSS, está disponível como plugin no catálogo, exigindo uma conta Grafana Cloud.\nPara o mercado brasileiro, o suporte a Oracle, Zabbix e MongoDB é particularmente interessante, já que são tecnologias com presença significativa em ambientes corporativos e provedores de serviços por aqui.\nMelhorias em dashboards # A experiência de criação e uso de dashboards recebeu várias atualizações na 13.1.\nVariáveis por seção (GA) # Esta é uma das funcionalidades mais pedidas pela comunidade. Antes, variáveis como $service ou $environment tinham escopo global no dashboard. Agora é possível definir variáveis no nível de linhas e abas, permitindo que cada seção do dashboard tenha seu próprio contexto.\nExemplo prático: em um dashboard que monitora produção e homologação lado a lado, você pode ter uma variável $service diferente para cada linha, sem conflitos.\nEditor de queries reformulado (public preview) # O editor de queries foi redesenhado com foco em produtividade:\nSeleção múltipla e ações em lote — selecione várias queries de uma vez para editar, duplicar ou remover Visão empilhada — visualização lado a lado das queries abertas, facilitando a comparação Para times que mantêm dashboards com dezenas de painéis, a economia de tempo é significativa.\nFiltros rápidos e agrupamento de dados (GA) # Os quick filters permitem aplicar filtros ad-hoc sem modificar as queries subjacentes. O agrupamento de dados agora é estável e funciona diretamente na interface, simplificando a criação de visões agregadas.\nVisibilidade de séries em legendas de séries temporais # A legenda dos gráficos de série temporal agora inclui um controle de visibilidade por série. Isso permite ocultar ou exibir linhas individualmente, útil em dashboards com múltiplas métricas sobrepostas.\nTabelas aninhadas melhoradas # As tabelas aninhadas (nested tables) receberam melhorias em:\nAgrupamento configurável — defina como os dados são agrupados dentro de cada célula Estilização de células — formatação condicional com cores e estilos Agregações aprimoradas — novas funções de agregação para sumarizar dados aninhados Copiar e colar estilos de painel (GA) # Finalmente é possível copiar a configuração de estilo de um painel e aplicar em outro, sem precisar reconfigurar manualmente cores, thresholds e formatação.\nPresets de estilo de painel (GA) # O Grafana 13.1 inclui presets de estilo — combinações curadas de cores, thresholds e formatação para tipos comuns de painel (gráficos de barra, medidores, tabelas, etc.). Isso acelera a criação de dashboards com aparência consistente.\nPDC (Private Data Source Connect): novos data sources # O PDC, que permite conexões seguras via túnel criptografado para fontes de dados em redes privadas, ganhou suporte a três novos tipos:\nMQTT — protocolo IoT (Internet das Coisas) GitHub — API do GitHub para métricas de repositórios IBM Db2 — banco de dados relacional da IBM Essas adições ampliam o alcance do PDC para cenários de IoT, integração com DevOps e bancos corporativos legados, mantendo todo o tráfego criptografado entre o Grafana e a fonte de dados.\nConclusão # A Grafana 13.1 consolida o Git Sync como ferramenta madura para observability as code, expande o alcance do assistente de IA para fontes de dados muito utilizadas no mercado brasileiro e entrega melhorias práticas no dia a dia de quem constrói e mantém dashboards.\nPara quem utiliza Grafana Enterprise, o destaque fica com o Grafana Assistant já incluso, sem necessidade de plugins adicionais. Para usuários OSS, as melhorias em Git Sync, variáveis por seção e editor de queries são os motivos mais fortes para atualizar.\nNa EF-TECH, ajudamos empresas a implementar e gerenciar soluções de observabilidade com Grafana. Entre em contato.\n","date":"26 junho 2026","externalUrl":null,"permalink":"/pt-br/blog/grafana-13-1/","section":"Soluções em Cloud Computing","summary":"A Grafana 13.1 traz Git Sync em GA com commits assinados, suporte do Grafana Assistant a bancos como Oracle e MongoDB, variáveis por seção, editor de queries reformulado e novos data sources no PDC. Um resumo prático para quem trabalha com observabilidade no dia a dia.","title":"Grafana 13.1: Novidades em observability as code, Grafana Assistant e mais","type":"pt-br"},{"content":"Grafana Labs has released version 13.1, building on the foundation laid by Grafana 13 which brought Git Sync to general availability. This release is especially relevant for teams embracing observability as code, managing dynamic dashboards across multiple services, or connecting to on-premise data sources through secure tunnels.\nHere is a breakdown of the key changes organized by area of interest.\nGit Sync: Observability as code matures # Git Sync, which reached GA in Grafana 13, continues to receive meaningful improvements in 13.1. For teams managing dashboards as code, this remains the centerpiece of the release.\nDashboard import into provisioned folders (GA) # Dashboards can now be imported directly into folders managed by provisioning. This means you can define your folder structure through configuration files and have Git-synced dashboards land in the correct location automatically, without manual intervention.\nRoot-level sync (GA) # Support for syncing from the repository root removes the need for specific directory structures. Simply configure the desired path and Grafana interprets your repository\u0026rsquo;s natural layout.\nREADME.md rendering in Git Sync folders (public preview) # Folders synced via Git Sync now display the repository\u0026rsquo;s README.md file directly inside Grafana. This enables inline documentation for each dashboard set, especially useful for teams maintaining multiple observability repositories.\nSigned commits with GPG, SSH, and S/MIME (GA) # Every change made through Git Sync can be digitally signed, ensuring traceability and compliance. Support covers GPG, SSH, and S/MIME, suiting teams from small setups to enterprise environments with strict auditing policies.\nGitHub App, GitLab, and BitBucket integration # Git Sync supports authentication via GitHub App (recommended for GitHub-based organizations), GitLab, BitBucket, and plain Git connections, covering most real-world scenarios.\nGrafana Assistant expands to 8 new data sources # The AI-powered assistant that helps users build queries and interpret metrics now supports eight additional data sources:\nSnowflake — cloud data warehouse Oracle — enterprise relational database Elasticsearch — log search and analytics Dynatrace — application performance monitoring Honeycomb — event-driven observability Zabbix — open source infrastructure monitoring Jira — project management and ticketing MongoDB — NoSQL database Availability # The Grafana Assistant comes pre-installed with Grafana Enterprise (no extra plugin required). OSS users can install it from the plugin catalog, which requires a Grafana Cloud account.\nFor organizations running mixed stacks, the addition of Oracle, Elasticsearch, and MongoDB means the assistant can now help across a broader range of backend technologies.\nDashboarding improvements # The dashboard authoring and consumption experience received several updates in 13.1.\nSection-level variables (GA) # This is one of the most requested community features. Previously, variables like $service or $environment applied globally across the entire dashboard. Now you can define variables scoped to rows and tabs, allowing each dashboard section to have its own context.\nPractical example: in a dashboard monitoring both production and staging side by side, you can have a different $service variable per row without conflicts.\nRedesigned query editor (public preview) # The query editor has been reworked for productivity:\nMulti-select and bulk actions — select multiple queries at once to edit, duplicate, or delete Stacked view — side-by-side visualization of open queries for easier comparison For teams maintaining dashboards with dozens of panels, the time savings are substantial.\nQuick filters and data grouping (GA) # Quick filters let you apply ad-hoc filters without modifying underlying queries. Data grouping is now stable and works directly from the UI, simplifying the creation of aggregated views.\nSeries visibility in time series legends # Time series chart legends now include per-series visibility controls. You can hide or show individual lines directly from the legend, useful in dashboards with multiple overlapping metrics.\nEnhanced nested tables # Nested tables received improvements in:\nConfigurable grouping — define how data is grouped within each cell Cell styling — conditional formatting with colors and styles Improved aggregations — new aggregation functions for summarizing nested data Copy and paste panel styles (GA) # You can now copy style configuration from one panel and apply it to another, eliminating the need to manually reconfigure colors, thresholds, and formatting.\nPanel style presets (GA) # Grafana 13.1 includes curated style presets — combinations of colors, thresholds, and formatting for common panel types (bar charts, gauges, tables, etc.). This accelerates dashboard creation while maintaining visual consistency.\nPDC (Private Data Source Connect): new data sources # PDC, which enables secure encrypted tunnel connections to data sources on private networks, now supports three new types:\nMQTT — IoT (Internet of Things) protocol GitHub — GitHub API for repository metrics IBM Db2 — IBM relational database These additions extend PDC reach to IoT scenarios, DevOps integration, and legacy enterprise databases, all while keeping traffic encrypted between Grafana and the data source.\nConclusion # Grafana 13.1 solidifies Git Sync as a mature tool for observability as code, expands the AI assistant to data sources widely used in enterprise environments, and delivers practical improvements for day-to-day dashboard work.\nFor Grafana Enterprise users, the highlight is the built-in Grafana Assistant with no additional plugins required. For OSS users, the Git Sync enhancements, section-level variables, and redesigned query editor are the strongest reasons to upgrade.\nAt EF-TECH, we help companies implement and manage Grafana observability solutions. Contact us.\n","date":"26 junho 2026","externalUrl":null,"permalink":"/en/blog/grafana-13-1/","section":"Cloud Computing Solutions","summary":"Grafana 13.1 brings Git Sync to GA with signed commits, Grafana Assistant support for Oracle, MongoDB, Elasticsearch and more, section-scoped variables, a redesigned query editor, and three new PDC data sources. A practical overview for observability practitioners.","title":"Grafana 13.1: What's new in observability as code, Grafana Assistant, and more","type":"en"},{"content":"","date":"26 junho 2026","externalUrl":null,"permalink":"/tags/monitoramento/","section":"Tags","summary":"","title":"Monitoramento","type":"tags"},{"content":"","date":"26 junho 2026","externalUrl":null,"permalink":"/tags/monitoring/","section":"Tags","summary":"","title":"Monitoring","type":"tags"},{"content":"","date":"26 junho 2026","externalUrl":null,"permalink":"/tags/observabilidade/","section":"Tags","summary":"","title":"Observabilidade","type":"tags"},{"content":"","date":"26 junho 2026","externalUrl":null,"permalink":"/tags/observability/","section":"Tags","summary":"","title":"Observability","type":"tags"},{"content":"","date":"24 junho 2026","externalUrl":null,"permalink":"/tags/docker/","section":"Tags","summary":"","title":"Docker","type":"tags"},{"content":"GLPI 11.0.8 was released today as a security release — upgrading is recommended for all environments. This version fixes 16 vulnerabilities, including 2 critical and 8 high severity.\nSecurity highlights # Critical Vulnerabilities # CVE-2026-48482 — RCE via Form import CVE-2026-52848 — MFA bypass High Vulnerabilities # CVE-2026-47678 — SQL injection in dropdowns CVE-2026-47679 — Arbitrary file deletion CVE-2026-49470 — Account takeover via 2FA brute force CVE-2026-53625 — Privilege escalation via authtype API CVE-2026-53610 — Reflected XSS in dashboards CVE-2026-53626 — Arbitrary document read CVE-2026-53629 — SQL injection in history tab CVE-2026-55214 — Stored XSS in suppliers Medium Vulnerabilities # Unauthorized debug mode activation, LDAP filter injection, unallowed authentication method update, unexpected API update access, unallowed knowledge base comment modification, and unallowed notification sending.\nDocker Images and Helm Chart # We published Docker images and Helm Chart for both GLPI versions:\nComponent Version GLPI (app) 11.0.8 GLPI (app) 10.0.26 Helm Chart glpi-11.0.8 Links # GLPI 11.0.8 Release Docker Images and Helm Chart EF-TECH GLPI Repository Upgrade via Helm # helm repo add eftech https://eftechcombr.github.io/glpi/charts helm repo update helm upgrade --install glpi eftech/glpi --namespace glpi --version 11.0.8 Upgrade via Docker # docker pull ghcr.io/eftechcombr/glpi:11.0.8 This upgrade is especially critical if you use Form import functionality (RCE) or multi-factor authentication (bypass). We recommend upgrading as soon as possible.\nAt EF-TECH, we offer specialized support for GLPI deployment and maintenance in containers. Contact us to learn more.\n","date":"24 junho 2026","externalUrl":null,"permalink":"/en/blog/glpi-11-0-8/","section":"Cloud Computing Solutions","summary":"EF-TECH releases Docker images and Helm Chart for GLPI 11.0.8 and 10.0.26. Version 11.0.8 is a security release with 16 fixed vulnerabilities.","title":"GLPI 11.0.8 and 10.0.26: Updated Docker Images and Helm Chart","type":"en"},{"content":"O GLPI 11.0.8 foi lançado hoje como um security release — a atualização é recomendada para todos os ambientes. Esta versão corrige 16 vulnerabilidades, sendo 2 críticas e 8 de alta severidade.\nDestaques de segurança # Vulnerabilidades Críticas # CVE-2026-48482 — RCE via importação de formulários CVE-2026-52848 — Bypass de MFA (autenticação multifator) Vulnerabilidades Altas # CVE-2026-47678 — SQL injection em dropdowns CVE-2026-47679 — Deleção arbitrária de arquivos CVE-2026-49470 — Account takeover via brute force em 2FA CVE-2026-53625 — Escalação de privilégio via API de authtype CVE-2026-53610 — Reflected XSS em dashboards CVE-2026-53626 — Leitura arbitrária de documentos CVE-2026-53629 — SQL injection no histórico CVE-2026-55214 — Stored XSS em fornecedores Vulnerabilidades Médias # Debug mode não autorizado, injeção em filtro LDAP, atualização não autorizada de método de autenticação, acesso inesperado a operações de update via API, modificação não autorizada de comentários em knowledge base e envio não autorizado de notificações. Imagens Docker e Helm Chart # Disponibilizamos as imagens Docker e Helm Chart para as duas versões do GLPI:\nComponente Versão GLPI (app) 11.0.8 GLPI (app) 10.0.26 Helm Chart glpi-11.0.8 Links # Release GLPI 11.0.8 Imagens Docker e Helm Chart Repositório oficial EF-TECH GLPI Atualização via Helm # helm repo add eftech https://eftechcombr.github.io/glpi/charts helm repo update helm upgrade --install glpi eftech/glpi --namespace glpi --version 11.0.8 Atualização via Docker # docker pull ghcr.io/eftechcombr/glpi:11.0.8 A atualização é especialmente crítica para quem utiliza a funcionalidade de importação de formulários (RCE) ou autenticação multifator (bypass). Recomendamos o upgrade o quanto antes.\nNa EF-TECH, oferecemos suporte especializado para implantação e manutenção de GLPI em contêineres. Entre em contato para saber mais.\n","date":"24 junho 2026","externalUrl":null,"permalink":"/pt-br/blog/glpi-11-0-8/","section":"Soluções em Cloud Computing","summary":"A EF-TECH disponibiliza as imagens Docker e Helm Chart para GLPI 11.0.8 e 10.0.26. A versão 11.0.8 é um security release com correção de 16 vulnerabilidades.","title":"GLPI 11.0.8 e 10.0.26: imagens Docker e Helm Chart atualizados","type":"pt-br"},{"content":"","date":"24 junho 2026","externalUrl":null,"permalink":"/tags/helm/","section":"Tags","summary":"","title":"Helm","type":"tags"},{"content":"","date":"24 junho 2026","externalUrl":null,"permalink":"/tags/security/","section":"Tags","summary":"","title":"Security","type":"tags"},{"content":"","date":"24 junho 2026","externalUrl":null,"permalink":"/tags/seguranca/","section":"Tags","summary":"","title":"Seguranca","type":"tags"},{"content":"","date":"22 junho 2026","externalUrl":null,"permalink":"/tags/aws/","section":"Tags","summary":"","title":"Aws","type":"tags"},{"content":"O AWS Summit São Paulo 2026 está chegando! O maior evento de cloud computing da América Latina será realizado no dia 3 de setembro de 2026 no São Paulo Expo, com retirada antecipada de crachás já no dia 2 de setembro.\nO evento é gratuito e reunirá profissionais de tecnologia, líderes de TI, desenvolvedores e entusiastas de cloud para um dia inteiro de conteúdo, networking e inovação.\nDestaques do evento # +170 Sessões técnicas # De histórias de sucesso de clientes a soluções inovadoras de nuvem, o AWS Summit oferece uma grade com mais de 170 sessões apresentadas por especialistas da AWS e clientes que transformaram seus negócios com a nuvem.\nKeynote # O keynote do AWS Summit São Paulo 2026 explorará como a AWS equipa desenvolvedores com ferramentas e recursos para tirar todas as ideias do papel. Clientes que alcançaram grandes marcos compartilharão suas experiências reais.\nAWS Village # Experimente as inovações mais recentes da AWS com orientação especializada que transforma sua jornada para a nuvem.\nAtivação de agentes 8-bit # Uma das atrações mais criativas do evento: crie e implante agentes de IA em minutos e veja seu sprite 8-bit personalizado resolver desafios de forma autônoma.\nAWS Sports Zone # Descubra inovação de ponta em IA por meio de demos práticas como Football for All e NBA PlayFinder.\nAWS Startup Zone # Construindo a próxima grande inovação? Conecte-se com especialistas e pares da AWS e acesse recursos para acelerar o crescimento da sua startup.\nAWS para Indústrias # Soluções personalizadas para desafios únicos de cada setor, com especialistas da AWS prontos para ajudar.\nTreinamento e Certificação # Melhore sua experiência na nuvem AWS com aprendizado prático, desafios e treinamento ministrado por especialistas.\nProgramação # 2 de setembro de 2026\n11h - 19h | Retirada antecipada de crachás 3 de setembro de 2026\n7h - 18h | Retirada de crachás 8h - 18h | Área de exposição 8h - 17h30 | Sessões de conteúdo 10h30 - 11h30 | Keynote 17h30 - 18h30 | Happy Hour na Área de Exposição 18h30 | Encerramento do evento Por que participar? # Explore maneiras de transformar negócios com a AWS, desde IA agêntica até computação sem servidor Desenvolva habilidades essenciais para tirar futuros projetos do papel com conteúdo técnico aprofundado e demonstrações práticas Conecte-se com líderes do setor, colaboradores e especialistas da AWS Inscreva-se # O evento é gratuito, mas as vagas são limitadas. Garanta sua presença no maior evento de cloud da América Latina.\nInscreva-se agora no AWS Summit São Paulo 2026\nA EF-TECH estará presente no evento! Se você vai participar e quer conversar sobre cloud, infraestrutura ou IA, entre em contato — vamos marcar um encontro por lá.\n","date":"22 junho 2026","externalUrl":null,"permalink":"/pt-br/blog/aws-summit-sao-paulo-2026/","section":"Soluções em Cloud Computing","summary":"O AWS Summit São Paulo 2026 acontece em 3 de setembro no São Paulo Expo. Confira os destaques: +170 sessões, keynote, AWS Village, zona de startups e ativação de agentes de IA 8-bit.","title":"AWS Summit São Paulo 2026: o maior evento de cloud da América Latina","type":"pt-br"},{"content":"The AWS Summit São Paulo 2026 is coming! The largest cloud computing event in Latin America will take place on September 3, 2026 at the São Paulo Expo, with early badge pickup available on September 2.\nThe event is free and brings together IT professionals, tech leaders, developers, and cloud enthusiasts for a full day of content, networking, and innovation.\nEvent highlights # +170 Technical sessions # From customer success stories to innovative cloud solutions, the AWS Summit offers over 170 sessions presented by AWS experts and customers who transformed their businesses with the cloud.\nKeynote # The AWS Summit São Paulo 2026 keynote will explore how AWS empowers developers with tools and resources to bring every idea to life. Customers who achieved major milestones will share their real-world experiences.\nAWS Village # Experience the latest AWS innovations with expert guidance to transform your cloud journey.\n8-bit Agent Activation # One of the most creative attractions: build and deploy AI agents in minutes and watch your custom 8-bit sprite solve challenges autonomously.\nAWS Sports Zone # Cutting-edge AI innovation through hands-on demos like Football for All and NBA PlayFinder.\nAWS Startup Zone # Building the next big thing? Connect with AWS experts and peers, and access resources to accelerate your startup\u0026rsquo;s growth.\nAWS for Industries # Tailored solutions for each industry\u0026rsquo;s unique challenges, with AWS experts ready to help.\nTraining and Certification # Level up your AWS cloud skills with hands-on learning, challenges, and expert-led training.\nSchedule # September 2, 2026\n11:00 - 19:00 | Early badge pickup September 3, 2026\n7:00 - 18:00 | Badge pickup 8:00 - 18:00 | Exhibition area 8:00 - 17:30 | Content sessions 10:30 - 11:30 | Keynote 17:30 - 18:30 | Happy Hour at Exhibition Area 18:30 | Event closing Why attend? # Explore ways to transform businesses with AWS, from agentic AI to serverless computing Build essential skills with deep technical content and hands-on demonstrations Connect with industry leaders, peers, and AWS experts Register now # The event is free, but spots are limited. Secure your place at the largest cloud event in Latin America.\nRegister for AWS Summit São Paulo 2026\nEF-TECH will be at the event! If you\u0026rsquo;re attending and want to talk about cloud, infrastructure, or AI, get in touch — let\u0026rsquo;s schedule a meetup there.\n","date":"22 junho 2026","externalUrl":null,"permalink":"/en/blog/aws-summit-sao-paulo-2026/","section":"Cloud Computing Solutions","summary":"AWS Summit São Paulo 2026 happens on September 3 at São Paulo Expo. Check out the highlights: +170 sessions, keynote, AWS Village, startup zone, and 8-bit AI agent activation.","title":"AWS Summit São Paulo 2026: the largest cloud event in Latin America","type":"en"},{"content":"","date":"22 junho 2026","externalUrl":null,"permalink":"/categories/cloud-computing/","section":"Categories","summary":"","title":"Cloud-Computing","type":"categories"},{"content":"","date":"22 junho 2026","externalUrl":null,"permalink":"/tags/cloud-computing/","section":"Tags","summary":"","title":"Cloud-Computing","type":"tags"},{"content":"","date":"22 junho 2026","externalUrl":null,"permalink":"/tags/event/","section":"Tags","summary":"","title":"Event","type":"tags"},{"content":"","date":"22 junho 2026","externalUrl":null,"permalink":"/tags/evento/","section":"Tags","summary":"","title":"Evento","type":"tags"},{"content":"","date":"22 junho 2026","externalUrl":null,"permalink":"/tags/migracao/","section":"Tags","summary":"","title":"Migracao","type":"tags"},{"content":"Neste final de semana realizamos a migração do banco de dados do GLPI — que até então operava dentro de um StatefulSet no Kubernetes — para o MySQL HeatWave da Oracle Cloud, utilizando os recursos do programa Always Free.\nO cenário anterior # O GLPI da EF-TECH rodava com banco de dados em um StatefulSet Kubernetes com armazenamento persistente via PVC. Embora funcional, esse modelo trazia desafios:\nGerenciamento manual de backups — sem snapshot automatizado fora do cluster Consumo de recursos do cluster — CPU e memória do banco competiam com os demais workloads Manutenção do MySQL — atualizações de versão e tuning exigiam intervenção manual nos pods Alta disponibilidade limitada — o StatefulSet com um único réplica era um ponto único de falha A solução: Oracle MySQL HeatWave # A Oracle Cloud oferece no programa Always Free um DB System MySQL HeatWave com:\n50 GB de armazenamento para dados 50 GB adicionais para backups automatizados Instância standalone gerenciada — sem preocupação com manutenção do sistema operacional ou do MySQL Backups automáticos — retenção configurável sem custo adicional Além disso, ao sair do cluster Kubernetes, liberamos recursos para os workloads principais e eliminamos a complexidade de operar um banco de dados stateful dentro do Kubernetes.\nO processo de migração # A migração foi planejada para causar o menor impacto possível:\nProvisionamento do DB System MySQL HeatWave no OCI (região home) Exportação do banco de dados do StatefulSet Kubernetes com mysqldump Importação dos dados para a instância MySQL na Oracle Cloud Atualização da string de conexão na aplicação GLPI (ConfigMap + variáveis de ambiente) Redirecionamento do tráfego e validação dos dados Desativação do StatefulSet antigo Comandos utilizados # Exportação dos dados do StatefulSet:\nkubectl exec -n glpi deployment/glpi-mysql -- \\ mysqldump --all-databases --single-transaction --quick \\ -u root -p\u0026#34;$MYSQL_ROOT_PASSWORD\u0026#34; \u0026gt; glpi-backup.sql Importação para o MySQL HeatWave:\nmysql -h \u0026lt;oci-mysql-host\u0026gt; -u admin -p \u0026lt; glpi-backup.sql Atualização da configuração no ConfigMap do GLPI:\nkubectl edit configmap glpi-config -n glpi # Atualizar: GLPI_DB_HOST, GLPI_DB_PORT, GLPI_DB_USER, GLPI_DB_PASSWORD Observabilidade com Grafana # Com o banco de dados agora rodando fora do cluster, aproveitamos para configurar o monitoramento via Grafana com métricas do MySQL HeatWave. Os principais dashboards incluem:\nConexões ativas — número de conexões simultâneas com o GLPI Consultas por segundo (QPS) — volume de queries e tendências de carga Tempo de resposta (latência) — p95 e p99 das consultas mais lentas Uso de armazenamento — crescimento do banco ao longo do tempo Backups — status e retenção dos backups automáticos Alertas — notificações para conexões acima do threshold, replicação atrasada e espaço em disco Primeiros resultados # Após as primeiras horas de operação, os resultados já são positivos:\nMétrica Antes (StatefulSet) Depois (MySQL HeatWave) Latência média de queries ~12 ms ~4 ms Tempo de backup manual ~25 min Automático (zero esforço) Recursos do cluster liberados — 2 vCPUs e 4 GB RAM Manutenção do MySQL Manual Gerenciada pela Oracle Próximos passos # Durante esta semana vamos acompanhar de perto as métricas no Grafana para:\nValidar a estabilidade da conexão entre o GLPI (no Kubernetes) e o MySQL (no OCI) Ajustar thresholds de alerta conforme a linha de base de operação Avaliar a necessidade de tuning de queries específicas do GLPI Documentar o processo para replicação em outros ambientes Tem GLPI rodando na sua infraestrutura e quer migrar para um modelo mais sustentável? A EF-TECH tem experiência em planejar e executar migrações de banco de dados com segurança e mínimo downtime. Entre em contato para conversarmos.\n","date":"22 junho 2026","externalUrl":null,"permalink":"/pt-br/blog/migracao-glpi-mysql-oracle/","section":"Soluções em Cloud Computing","summary":"Neste final de semana migramos o banco de dados do GLPI que rodava em StatefulSet Kubernetes para o MySQL HeatWave da Oracle Cloud (Always Free). Agora o monitoramento com Grafana já está mostrando os primeiros resultados.","title":"Migração do banco GLPI: de StatefulSet para MySQL na Oracle Cloud","type":"pt-br"},{"content":"This weekend we migrated the GLPI database — which previously operated inside a StatefulSet on Kubernetes — to MySQL HeatWave on Oracle Cloud, using the resources from the Always Free program.\nThe previous setup # EF-TECH\u0026rsquo;s GLPI ran with its database on a Kubernetes StatefulSet with persistent storage via PVC. While functional, this model came with challenges:\nManual backup management — no automated snapshot outside the cluster Cluster resource consumption — database CPU and memory competed with other workloads MySQL maintenance — version updates and tuning required manual pod intervention Limited high availability — the single-replica StatefulSet was a single point of failure The solution: Oracle MySQL HeatWave # Oracle Cloud offers a MySQL HeatWave DB System under the Always Free program with:\n50 GB of storage for data 50 GB additional for automated backups Managed standalone instance — no worries about OS or MySQL maintenance Automatic backups — configurable retention at no additional cost Additionally, by moving out of the Kubernetes cluster, we freed up resources for main workloads and eliminated the complexity of operating a stateful database inside Kubernetes.\nThe migration process # The migration was planned for minimal impact:\nProvisioning the MySQL HeatWave DB System on OCI (home region) Exporting the database from the Kubernetes StatefulSet using mysqldump Importing the data into the Oracle Cloud MySQL instance Updating the connection string in the GLPI application (ConfigMap + environment variables) Redirecting traffic and validating the data Decommissioning the old StatefulSet Commands used # Exporting data from the StatefulSet:\nkubectl exec -n glpi deployment/glpi-mysql -- \\ mysqldump --all-databases --single-transaction --quick \\ -u root -p\u0026#34;$MYSQL_ROOT_PASSWORD\u0026#34; \u0026gt; glpi-backup.sql Importing into MySQL HeatWave:\nmysql -h \u0026lt;oci-mysql-host\u0026gt; -u admin -p \u0026lt; glpi-backup.sql Updating the configuration in the GLPI ConfigMap:\nkubectl edit configmap glpi-config -n glpi # Update: GLPI_DB_HOST, GLPI_DB_PORT, GLPI_DB_USER, GLPI_DB_PASSWORD Observability with Grafana # With the database now running outside the cluster, we took the opportunity to set up monitoring via Grafana with MySQL HeatWave metrics. The main dashboards include:\nActive connections — number of simultaneous connections to GLPI Queries per second (QPS) — query volume and load trends Response time (latency) — p95 and p99 of slowest queries Storage usage — database growth over time Backups — automated backup status and retention Alerts — notifications for connections above threshold, delayed replication, and disk space First results # After the first hours of operation, the results are already positive:\nMetric Before (StatefulSet) After (MySQL HeatWave) Average query latency ~12 ms ~4 ms Manual backup time ~25 min Automatic (zero effort) Cluster resources freed — 2 vCPUs and 4 GB RAM MySQL maintenance Manual Managed by Oracle Next steps # Throughout this week we will closely monitor the Grafana metrics to:\nValidate connection stability between GLPI (on Kubernetes) and MySQL (on OCI) Adjust alert thresholds based on the operational baseline Assess the need for tuning specific GLPI queries Document the process for replication in other environments Is GLPI running on your infrastructure and you want to migrate to a more sustainable model? EF-TECH has experience planning and executing database migrations safely with minimal downtime. Contact us to talk.\n","date":"22 junho 2026","externalUrl":null,"permalink":"/en/blog/migracao-glpi-mysql-oracle/","section":"Cloud Computing Solutions","summary":"This weekend we migrated the GLPI database that was running on a Kubernetes StatefulSet to Oracle Cloud MySQL HeatWave (Always Free). Grafana monitoring is already showing the first results.","title":"Migrating GLPI Database: From StatefulSet to MySQL on Oracle Cloud","type":"en"},{"content":"","date":"22 junho 2026","externalUrl":null,"permalink":"/tags/migration/","section":"Tags","summary":"","title":"Migration","type":"tags"},{"content":"","date":"22 junho 2026","externalUrl":null,"permalink":"/tags/mysql/","section":"Tags","summary":"","title":"Mysql","type":"tags"},{"content":"","date":"22 junho 2026","externalUrl":null,"permalink":"/tags/oracle-cloud/","section":"Tags","summary":"","title":"Oracle-Cloud","type":"tags"},{"content":"","date":"22 junho 2026","externalUrl":null,"permalink":"/tags/saopaulo/","section":"Tags","summary":"","title":"Saopaulo","type":"tags"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/banco-de-dados/","section":"Tags","summary":"","title":"Banco-De-Dados","type":"tags"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/chatgpt/","section":"Tags","summary":"","title":"Chatgpt","type":"tags"},{"content":"O Hermes Agent é uma ferramenta poderosa para orquestração de agentes de IA. Neste guia, você vai aprender a instalá-lo em um cluster Kubernetes utilizando os manifestos disponíveis no repositório da EF-TECH.\nVamos cobrir cada recurso necessário — desde o ConfigMap até o Ingress — explicando o papel de cada componente e como aplicá-los com kubectl e Kustomize.\nPré-requisitos # Antes de começar, certifique-se de ter:\nUm cluster Kubernetes (v1.19+) kubectl configurado para acessar o cluster kustomize instalado (ou kubectl v1.21+ com suporte nativo a -k) cert-manager instalado (para TLS) Uma StorageClass compatível (o exemplo usa longhorn) Reloader (opcional, para recarga automática de secrets) Estrutura dos manifestos # Os arquivos de manifesto estão organizados no diretório iac/files/kubernetes/hermes/:\niac/files/kubernetes/hermes/ ├── configmap.yaml ├── deployment.yaml ├── ingress.yaml ├── issuer.yaml ├── kustomization.yaml ├── persistentvolumeclaim.yaml └── service.yaml Passo 1: Namespace # Crie o namespace hermes para isolar os recursos:\nkubectl create namespace hermes Passo 2: ConfigMap # O ConfigMap define as variáveis de ambiente do Hermes Agent:\napiVersion: v1 kind: ConfigMap metadata: name: hermes-config labels: app.kubernetes.io/name: hermes app.kubernetes.io/part-of: hermes data: HERMES_DASHBOARD: \u0026#34;1\u0026#34; HERMES_UID: \u0026#34;10000\u0026#34; HERMES_GID: \u0026#34;10000\u0026#34; HERMES_DASHBOARD_HOST: \u0026#34;0.0.0.0\u0026#34; HERMES_DASHBOARD_INSECURE: \u0026#34;1\u0026#34; DASHBOARD_PORT: \u0026#34;9119\u0026#34; GATEWAY_PORT: \u0026#34;8642\u0026#34; API_SERVER_ENABLED: \u0026#34;true\u0026#34; API_SERVER_HOST: \u0026#34;0.0.0.0\u0026#34; WEBHOOK_ENABLED: \u0026#34;true\u0026#34; WEBHOOK_PORT: \u0026#34;8644\u0026#34; Principais variáveis:\nHERMES_DASHBOARD=1 — habilita o dashboard web API_SERVER_ENABLED=true — ativa a API REST WEBHOOK_ENABLED=true — ativa o webhook para integrações Portas: Gateway (8642), Dashboard (9119), Webhook (8644) Passo 3: Secrets # O deployment referencia um Secret externo chamado hermes-secret com a anotação secret.reloader.stakater.com/reload. Isso permite que o Reloader reinicie o pod automaticamente quando o secret for atualizado.\nCrie o secret manualmente:\nkubectl create secret generic hermes-secret \\ --namespace hermes \\ --from-literal=API_KEY=sua-chave-aqui \\ --from-literal=OUTH_TOKEN=seu-token-aqui Nota: Os valores exatos dependem da configuração do seu Hermes Agent. Consulte a documentação oficial para obter a lista completa de variáveis esperadas.\nPasso 4: PersistentVolumeClaim # O Hermes Agent precisa de armazenamento persistente para dados. O PVC solicita 5Gi em um storage class longhorn:\napiVersion: v1 kind: PersistentVolumeClaim metadata: name: hermes-data labels: app.kubernetes.io/name: hermes app.kubernetes.io/part-of: hermes spec: accessModes: - ReadWriteOnce storageClassName: longhorn resources: requests: storage: 5Gi Ajuste o storageClassName conforme a disponível no seu cluster (use standard, gp2, ebs-sc etc.).\nPasso 5: Deployment # O Deployment gerencia o pod do Hermes Agent com a imagem nousresearch/hermes-agent:latest:\napiVersion: apps/v1 kind: Deployment metadata: name: hermes labels: app.kubernetes.io/name: hermes app.kubernetes.io/part-of: hermes annotations: secret.reloader.stakater.com/reload: \u0026#34;hermes-secret\u0026#34; spec: replicas: 1 strategy: type: Recreate selector: matchLabels: app.kubernetes.io/name: hermes template: metadata: labels: app.kubernetes.io/name: hermes annotations: secret.reloader.stakater.com/reload: \u0026#34;hermes-secret\u0026#34; spec: restartPolicy: Always enableServiceLinks: false containers: - name: hermes image: nousresearch/hermes-agent:latest args: [\u0026#34;gateway\u0026#34;, \u0026#34;run\u0026#34;] envFrom: - configMapRef: name: hermes-config - secretRef: name: hermes-secret ports: - name: gateway containerPort: 8642 - name: dashboard containerPort: 9119 - name: webhook containerPort: 8644 livenessProbe: httpGet: path: /health port: gateway initialDelaySeconds: 120 periodSeconds: 15 readinessProbe: httpGet: path: /health port: gateway initialDelaySeconds: 15 periodSeconds: 10 resources: requests: memory: \u0026#34;256Mi\u0026#34; cpu: \u0026#34;100m\u0026#34; limits: memory: \u0026#34;4Gi\u0026#34; cpu: \u0026#34;1\u0026#34; volumeMounts: - name: hermes-data mountPath: /opt/data volumes: - name: hermes-data persistentVolumeClaim: claimName: hermes-data Pontos importantes: # Estratégia Recreate: necessária porque o volume ReadWriteOnce não pode ser montado por múltiplos pods simultaneamente Health checks: o readiness probe começa após 15s e o liveness probe após 120s (tempo para o agente inicializar) Recursos: requests baixos (256Mi/100m) com limits generosos (4Gi/1 CPU) para acomodar picos de uso Portas: três portas expostas — gateway (8642), dashboard (9119) e webhook (8644) Volume: montado em /opt/data para dados persistentes Passo 6: Services # Três Services do tipo ClusterIP expõem cada porta internamente no cluster:\n--- apiVersion: v1 kind: Service metadata: name: hermes-gateway labels: app.kubernetes.io/name: hermes app.kubernetes.io/part-of: hermes spec: type: ClusterIP selector: app.kubernetes.io/name: hermes ports: - name: gateway port: 8642 targetPort: gateway --- apiVersion: v1 kind: Service metadata: name: hermes-dashboard labels: app.kubernetes.io/name: hermes app.kubernetes.io/part-of: hermes spec: type: ClusterIP selector: app.kubernetes.io/name: hermes ports: - name: dashboard port: 9119 targetPort: dashboard --- apiVersion: v1 kind: Service metadata: name: hermes-webhook labels: app.kubernetes.io/name: hermes app.kubernetes.io/part-of: hermes spec: type: ClusterIP selector: app.kubernetes.io/name: hermes ports: - name: webhook port: 8644 targetPort: webhook Cada service mapeia pelo nome da porta definida no Deployment, garantindo o roteamento correto.\nPasso 7: TLS com cert-manager # O Issuer configura a emissão de certificados Let\u0026rsquo;s Encrypt:\napiVersion: cert-manager.io/v1 kind: Issuer metadata: name: letsencrypt-hermes-prod namespace: hermes spec: acme: email: suporte@eftech.com.br privateKeySecretRef: name: letsencrypt-hermes-prod server: https://acme-v02.api.letsencrypt.org/directory solvers: - http01: ingress: class: traefik Substitua o email pelo seu e-mail e ajuste class para o ingress controller do seu cluster (nginx, traefik, haproxy etc.).\nPasso 8: Ingress # O Ingress expõe o serviço externamente com TLS:\napiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: hermes-ingress annotations: cert-manager.io/issuer: \u0026#34;letsencrypt-hermes-prod\u0026#34; spec: ingressClassName: traefik tls: - hosts: - hermes.eftech.com.br secretName: hermes-tls rules: - host: hermes.eftech.com.br http: paths: - path: / pathType: Prefix backend: service: name: hermes-gateway port: number: 8642 Nota: O Ingress está comentado no kustomization.yaml por padrão. Descomente quando estiver pronto para expor o serviço.\nPasso 9: Aplicar tudo com Kustomize # Com o kustomization.yaml configurado, aplique todos os recursos de uma vez:\nkubectl apply -k iac/files/kubernetes/hermes/ --namespace hermes O Kustomize processa os arquivos na ordem correta: PVC → ConfigMap → Deployment → Services → Issuer → Ingress.\nVerificação # Confira se o pod está rodando:\nkubectl get pods -n hermes Acompanhe os logs:\nkubectl logs -n hermes -l app.kubernetes.io/name=hermes Teste o health check:\nkubectl port-forward -n hermes svc/hermes-gateway 8642:8642 curl http://localhost:8642/health Acesse o dashboard:\nkubectl port-forward -n hermes svc/hermes-dashboard 9119:9119 # Abra http://localhost:9119 no navegador Conclusão # Neste guia, você instalou o Hermes Agent no Kubernetes com:\nConfigMap para configuração centralizada Secrets gerenciados externamente com Reloader Persistência via PVC com Longhorn Deployment com health checks e limites de recursos Services para exposição interna cert-manager para TLS automático Ingress para acesso externo Toda a configuração é declarativa e versionada com Kustomize, facilitando manutenção e replicação em outros ambientes.\nNa EF-TECH, ajudamos empresas a planejar e executar implantações Kubernetes com foco em confiabilidade e boas práticas. Entre em contato para saber como podemos ajudar sua equipe.\n","date":"19 junho 2026","externalUrl":null,"permalink":"/pt-br/blog/hermes-k8s-install/","section":"Soluções em Cloud Computing","summary":"Aprenda a fazer deploy do Hermes Agent no Kubernetes com ConfigMap, Deployment, Services, cert-manager e Ingress — tudo gerenciado via Kustomize.","title":"Como instalar o Hermes Agent usando Kubernetes","type":"pt-br"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/database/","section":"Tags","summary":"","title":"Database","type":"tags"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/deploy/","section":"Tags","summary":"","title":"Deploy","type":"tags"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/categories/desenvolvimento/","section":"Categories","summary":"","title":"Desenvolvimento","type":"categories"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/categories/development/","section":"Categories","summary":"","title":"Development","type":"categories"},{"content":" GLPI # GLPI (Gestionnaire Libre de Parc Informatique) is an open-source IT asset management and ITIL service desk software. As an open-source solution, it offers features for hardware and software inventory, ticket creation and tracking, license tracking, and software auditing. The project is maintained by the community on GitHub and distributed under the GPL-3.0 license. EF-TECH specializes in containerized deployment and managed hosting of GLPI, bringing the versatility of open-source software to robust and secure production environments.\nITIL Service Desk # GLPI implements ITIL processes for service desk, allowing you to centralize and organize all IT support:\nIncident and problem management Change management Service Level Agreements (SLA) and escalation Knowledge base Service catalog Service request forms Asset Management and Inventory # GLPI\u0026rsquo;s asset management keeps your IT inventory always updated and traceable:\nAutomatic hardware inventory via agents Network discovery Equipment tracking by location, user, and status Asset lifecycle management Integration with inventory tools (OCS Inventory, FusionInventory) License Tracking and Software Audit # GLPI helps maintain license and software contract compliance:\nSoftware license control and compliance Installed software auditing License expiration alerts Contract and warranty management Compliance reports Containerized Deployment by EF-TECH # EF-TECH delivers GLPI production-ready with Docker images and Helm charts maintained by our team:\nOfficial Docker images: eftechcombr/glpi on Docker Hub GLPI 11.0.7 with PHP 8.4 and Nginx Deployment via Docker Compose for local and test environments Deployment via Kubernetes with Helm chart Helm chart repository: helm repo add eftechcombr https://eftechcombr.github.io/glpi/ Simple installation: helm install my-glpi eftechcombr/glpi Architecture with PHP-FPM, Nginx, MariaDB, and Redis Support for Ingress, Persistent Volumes, and auto-scaling on Kubernetes Repository: https://github.com/eftechcombr/glpi Managed Hosting and Support # For those who prefer to focus on their business, EF-TECH offers complete managed GLPI hosting:\nManaged hosting with 24/7 monitoring Support portal available at https://glpi.eftech.com.br Automated backup and disaster recovery Managed updates and patching Dedicated technical support Custom workflow and category configuration Interested in GLPI for your company? Contact us for a personalized consultation.\n","date":"19 junho 2026","externalUrl":null,"permalink":"/en/produtos/glpi/","section":"Cloud Computing Solutions","summary":"GLPI is an open-source IT asset management and ITIL service desk software. EF-TECH offers containerized deployment via Docker and Kubernetes with Helm chart, managed hosting, and dedicated support.","title":"GLPI","type":"en"},{"content":" GLPI # GLPI (Gestionnaire Libre de Parc Informatique) é um software livre de gestão de ativos de TI e service desk ITIL. Como solução open source, oferece recursos para inventário de hardware e software, abertura e controle de chamados, rastreamento de licenças e auditoria de software. O projeto é mantido pela comunidade no GitHub e distribuído sob licença GPL-3.0. A EF-TECH especializa-se no deploy containerizado e no hosting gerenciado do GLPI, levando a versatilidade do software livre para ambientes de produção robustos e seguros.\nService Desk ITIL # O GLPI implementa os processos ITIL para service desk, permitindo centralizar e organizar todo o atendimento de TI:\nGestão de incidentes e problemas Gestão de mudanças Acordos de Nível de Serviço (SLA) e escalonamento Base de conhecimento (knowledge base) Catálogo de serviços Formulários de solicitação de serviço (service catalog) Gestão de Ativos e Inventário # A gestão de ativos do GLPI mantém o inventário de TI sempre atualizado e rastreável:\nInventário automático de hardware via agentes Descoberta de rede (network discovery) Rastreamento de equipamentos por localização, usuário e estado Gestão do ciclo de vida de ativos Integração com ferramentas de inventário (OCS Inventory, FusionInventory) Rastreamento de Licenças e Auditoria de Software # O GLPI ajuda a manter a conformidade de licenças e contratos de software:\nControle de licenças de software e compliance Auditoria de software instalado Alertas de vencimento de licenças Gestão de contratos e garantias Relatórios de conformidade Deploy Containerizado pela EF-TECH # A EF-TECH entrega o GLPI pronto para produção com imagens Docker e Helm charts mantidos pela nossa equipe:\nImagens Docker oficiais: eftechcombr/glpi no Docker Hub GLPI 11.0.7 com PHP 8.4 e Nginx Deploy via Docker Compose para ambientes locais e de teste Deploy via Kubernetes com Helm chart Helm chart repository: helm repo add eftechcombr https://eftechcombr.github.io/glpi/ Instalação simples: helm install my-glpi eftechcombr/glpi Arquitetura com PHP-FPM, Nginx, MariaDB e Redis Suporte a Ingress, Persistent Volumes e auto-scaling no Kubernetes Repositorio: https://github.com/eftechcombr/glpi Hosting e Suporte Gerenciado # Para quem prefere focar no negocio, a EF-TECH oferece hosting gerenciado completo do GLPI:\nHosting gerenciado com monitoramento 24/7 Portal de suporte disponivel em https://glpi.eftech.com.br Backup automatizado e disaster recovery Atualizações e patching gerenciados Suporte técnico dedicado Configuração personalizada de fluxos de trabalho e categorias Interessado em GLPI para sua empresa? Entre em contato para uma consultoria personalizada.\n","date":"19 junho 2026","externalUrl":null,"permalink":"/pt-br/produtos/glpi/","section":"Soluções em Cloud Computing","summary":"GLPI é um software livre de gestão de ativos de TI e service desk ITIL. A EF-TECH oferece deploy containerizado via Docker e Kubernetes com Helm chart, hosting gerenciado e suporte dedicado.","title":"GLPI","type":"pt-br"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/hermes/","section":"Tags","summary":"","title":"Hermes","type":"tags"},{"content":"The Hermes Agent is a powerful tool for orchestrating AI agents. In this guide, you\u0026rsquo;ll learn how to install it on a Kubernetes cluster using the manifests available in the EF-TECH repository.\nWe\u0026rsquo;ll cover each required resource — from ConfigMap to Ingress — explaining the role of each component and how to apply them with kubectl and Kustomize.\nPrerequisites # Before you begin, make sure you have:\nA Kubernetes cluster (v1.19+) kubectl configured to access the cluster kustomize installed (or kubectl v1.21+ with native -k support) cert-manager installed (for TLS) A compatible StorageClass (the example uses longhorn) Reloader (optional, for automatic secret reloads) Manifest structure # The manifest files are organized in the iac/files/kubernetes/hermes/ directory:\niac/files/kubernetes/hermes/ ├── configmap.yaml ├── deployment.yaml ├── ingress.yaml ├── issuer.yaml ├── kustomization.yaml ├── persistentvolumeclaim.yaml └── service.yaml Step 1: Namespace # Create the hermes namespace to isolate resources:\nkubectl create namespace hermes Step 2: ConfigMap # The ConfigMap defines environment variables for the Hermes Agent:\napiVersion: v1 kind: ConfigMap metadata: name: hermes-config labels: app.kubernetes.io/name: hermes app.kubernetes.io/part-of: hermes data: HERMES_DASHBOARD: \u0026#34;1\u0026#34; HERMES_UID: \u0026#34;10000\u0026#34; HERMES_GID: \u0026#34;10000\u0026#34; HERMES_DASHBOARD_HOST: \u0026#34;0.0.0.0\u0026#34; HERMES_DASHBOARD_INSECURE: \u0026#34;1\u0026#34; DASHBOARD_PORT: \u0026#34;9119\u0026#34; GATEWAY_PORT: \u0026#34;8642\u0026#34; API_SERVER_ENABLED: \u0026#34;true\u0026#34; API_SERVER_HOST: \u0026#34;0.0.0.0\u0026#34; WEBHOOK_ENABLED: \u0026#34;true\u0026#34; WEBHOOK_PORT: \u0026#34;8644\u0026#34; Key variables:\nHERMES_DASHBOARD=1 — enables the web dashboard API_SERVER_ENABLED=true — enables the REST API WEBHOOK_ENABLED=true — enables webhooks for integrations Ports: Gateway (8642), Dashboard (9119), Webhook (8644) Step 3: Secrets # The deployment references an external Secret named hermes-secret with the annotation secret.reloader.stakater.com/reload. This allows Reloader to automatically restart the pod when the secret is updated.\nCreate the secret manually:\nkubectl create secret generic hermes-secret \\ --namespace hermes \\ --from-literal=API_KEY=your-key-here \\ --from-literal=OUTH_TOKEN=your-token-here Note: The exact values depend on your Hermes Agent configuration. Refer to the official documentation for the complete list of expected variables.\nStep 4: PersistentVolumeClaim # The Hermes Agent needs persistent storage for data. The PVC requests 5Gi on a longhorn storage class:\napiVersion: v1 kind: PersistentVolumeClaim metadata: name: hermes-data labels: app.kubernetes.io/name: hermes app.kubernetes.io/part-of: hermes spec: accessModes: - ReadWriteOnce storageClassName: longhorn resources: requests: storage: 5Gi Adjust storageClassName to match what\u0026rsquo;s available in your cluster (e.g., standard, gp2, ebs-sc).\nStep 5: Deployment # The Deployment manages the Hermes Agent pod using the nousresearch/hermes-agent:latest image:\napiVersion: apps/v1 kind: Deployment metadata: name: hermes labels: app.kubernetes.io/name: hermes app.kubernetes.io/part-of: hermes annotations: secret.reloader.stakater.com/reload: \u0026#34;hermes-secret\u0026#34; spec: replicas: 1 strategy: type: Recreate selector: matchLabels: app.kubernetes.io/name: hermes template: metadata: labels: app.kubernetes.io/name: hermes annotations: secret.reloader.stakater.com/reload: \u0026#34;hermes-secret\u0026#34; spec: restartPolicy: Always enableServiceLinks: false containers: - name: hermes image: nousresearch/hermes-agent:latest args: [\u0026#34;gateway\u0026#34;, \u0026#34;run\u0026#34;] envFrom: - configMapRef: name: hermes-config - secretRef: name: hermes-secret ports: - name: gateway containerPort: 8642 - name: dashboard containerPort: 9119 - name: webhook containerPort: 8644 livenessProbe: httpGet: path: /health port: gateway initialDelaySeconds: 120 periodSeconds: 15 readinessProbe: httpGet: path: /health port: gateway initialDelaySeconds: 15 periodSeconds: 10 resources: requests: memory: \u0026#34;256Mi\u0026#34; cpu: \u0026#34;100m\u0026#34; limits: memory: \u0026#34;4Gi\u0026#34; cpu: \u0026#34;1\u0026#34; volumeMounts: - name: hermes-data mountPath: /opt/data volumes: - name: hermes-data persistentVolumeClaim: claimName: hermes-data Key points: # Recreate strategy: required because ReadWriteOnce volumes cannot be mounted by multiple pods simultaneously Health checks: readiness probe starts after 15s, liveness probe after 120s (allowing time for agent initialization) Resources: low requests (256Mi/100m) with generous limits (4Gi/1 CPU) to handle usage spikes Ports: three exposed ports — gateway (8642), dashboard (9119), and webhook (8644) Volume: mounted at /opt/data for persistent data Step 6: Services # Three ClusterIP Services expose each port internally within the cluster:\n--- apiVersion: v1 kind: Service metadata: name: hermes-gateway labels: app.kubernetes.io/name: hermes app.kubernetes.io/part-of: hermes spec: type: ClusterIP selector: app.kubernetes.io/name: hermes ports: - name: gateway port: 8642 targetPort: gateway --- apiVersion: v1 kind: Service metadata: name: hermes-dashboard labels: app.kubernetes.io/name: hermes app.kubernetes.io/part-of: hermes spec: type: ClusterIP selector: app.kubernetes.io/name: hermes ports: - name: dashboard port: 9119 targetPort: dashboard --- apiVersion: v1 kind: Service metadata: name: hermes-webhook labels: app.kubernetes.io/name: hermes app.kubernetes.io/part-of: hermes spec: type: ClusterIP selector: app.kubernetes.io/name: hermes ports: - name: webhook port: 8644 targetPort: webhook Each service maps by port name as defined in the Deployment, ensuring correct routing.\nStep 7: TLS with cert-manager # The Issuer configures Let\u0026rsquo;s Encrypt certificate issuance:\napiVersion: cert-manager.io/v1 kind: Issuer metadata: name: letsencrypt-hermes-prod namespace: hermes spec: acme: email: suporte@eftech.com.br privateKeySecretRef: name: letsencrypt-hermes-prod server: https://acme-v02.api.letsencrypt.org/directory solvers: - http01: ingress: class: traefik Replace the email with yours and adjust class to match your ingress controller (nginx, traefik, haproxy, etc.).\nStep 8: Ingress # The Ingress exposes the service externally with TLS:\napiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: hermes-ingress annotations: cert-manager.io/issuer: \u0026#34;letsencrypt-hermes-prod\u0026#34; spec: ingressClassName: traefik tls: - hosts: - hermes.eftech.com.br secretName: hermes-tls rules: - host: hermes.eftech.com.br http: paths: - path: / pathType: Prefix backend: service: name: hermes-gateway port: number: 8642 Note: The Ingress is commented out in kustomization.yaml by default. Uncomment it when you\u0026rsquo;re ready to expose the service.\nStep 9: Apply everything with Kustomize # With kustomization.yaml configured, apply all resources at once:\nkubectl apply -k iac/files/kubernetes/hermes/ --namespace hermes Kustomize processes the files in the correct order: PVC → ConfigMap → Deployment → Services → Issuer → Ingress.\nVerification # Check that the pod is running:\nkubectl get pods -n hermes Follow the logs:\nkubectl logs -n hermes -l app.kubernetes.io/name=hermes Test the health check:\nkubectl port-forward -n hermes svc/hermes-gateway 8642:8642 curl http://localhost:8642/health Access the dashboard:\nkubectl port-forward -n hermes svc/hermes-dashboard 9119:9119 # Open http://localhost:9119 in your browser Conclusion # In this guide, you installed the Hermes Agent on Kubernetes with:\nConfigMap for centralized configuration Externally managed Secrets with Reloader Persistent storage via PVC with Longhorn Deployment with health checks and resource limits Services for internal exposure cert-manager for automatic TLS Ingress for external access The entire configuration is declarative and versioned with Kustomize, making it easy to maintain and replicate across environments.\nAt EF-TECH, we help companies plan and execute Kubernetes deployments focused on reliability and best practices. Contact us to learn how we can help your team.\n","date":"19 junho 2026","externalUrl":null,"permalink":"/en/blog/hermes-k8s-install/","section":"Cloud Computing Solutions","summary":"Learn how to deploy the Hermes Agent on Kubernetes with ConfigMap, Deployment, Services, cert-manager, and Ingress — all managed via Kustomize.","title":"How to Install the Hermes Agent on Kubernetes","type":"en"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/implantacao/","section":"Tags","summary":"","title":"Implantacao","type":"tags"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/infraestrutura/","section":"Tags","summary":"","title":"Infraestrutura","type":"tags"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/infrastructure/","section":"Tags","summary":"","title":"Infrastructure","type":"tags"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/integracao/","section":"Tags","summary":"","title":"Integracao","type":"tags"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/integration/","section":"Tags","summary":"","title":"Integration","type":"tags"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/inventario/","section":"Tags","summary":"","title":"Inventario","type":"tags"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/inventory/","section":"Tags","summary":"","title":"Inventory","type":"tags"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/itil/","section":"Tags","summary":"","title":"Itil","type":"tags"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/k8s/","section":"Tags","summary":"","title":"K8s","type":"tags"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/network/","section":"Tags","summary":"","title":"Network","type":"tags"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/oci/","section":"Tags","summary":"","title":"Oci","type":"tags"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/oracle/","section":"Tags","summary":"","title":"Oracle","type":"tags"},{"content":"O Oracle Cloud Infrastructure (OCI) oferece um dos programas Always Free mais generosos entre os grandes provedores de nuvem. Diferente de trials que expiram após 30 ou 90 dias, os recursos do Always Free estão disponíveis por tempo ilimitado na região home da sua conta.\nSe você está começando um projeto pessoal, fazendo provas de conceito ou estudando cloud computing, este guia detalha todos os recursos que você pode usar sem custo.\nCompute # O OCI oferece duas opções de instâncias Always Free:\nVM.Standard.E2.1.Micro (AMD) # Processador: 1/8 de um OCPU AMD (com burst) Memória: 1 GB Rede: 1 VNIC com 1 IP público, até 50 Mbps (internet) ou 480 Mbps (tráfego interno na região) Imagens: Oracle Linux, Oracle Linux Cloud Developer, Ubuntu, CentOS Limite: até 2 instâncias por conta VM.Standard.A1.Flex (ARM — Ampere) # Processador: até 2 OCPUs no total (configurável: 1 instância com 2 OCPUs ou 2 instâncias com 1 OCPU cada) Memória: até 12 GB no total Rede: largura de banda e VNICs escalam com o número de OCPUs Imagens: Oracle Linux, Oracle Linux Cloud Developer, Ubuntu Limite: 1.500 horas OCPU e 9.000 GB-hora por mês ⚠️ Instâncias ociosas podem ser recuperadas. Se por 7 dias consecutivos o uso de CPU for inferior a 20%, rede inferior a 20% e memória inferior a 20% (A1 apenas), a Oracle pode desligar a instância.\nArmazenamento # Block Volume # 200 GB totais combinados entre boot volumes e block volumes 5 backups de volume simultâneos O boot volume padrão de cada instância consome 50 GB desse total Volumes Always Free devem ser criados na região home Object Storage # 20 GB combinados entre Standard, Infrequent Access e Archive 50.000 requisições por mês à API de Object Storage Banco de Dados # Oracle Autonomous AI Database # 2 instâncias Always Free por tenancy 1 OCPU e 20 GB de armazenamento por instância Workloads suportadas: Transaction Processing, JSON Database, APEX Application Development e Lakehouse 20 sessões simultâneas por banco Oracle NoSQL Database # Até 133 milhões de leituras por mês Até 133 milhões de escritas por mês 3 tabelas com 25 GB cada Oracle MySQL HeatWave # 1 DB system standalone com HeatWave 50 GB de armazenamento para dados + 50 GB para backups Rede # Virtual Cloud Network (VCN) # Até 2 VCNs por tenancy (contas Free Tier) Suporte a IPv4 e IPv6 Load Balancer # 1 Load Balancer Flexible (10 Mbps mín/máx) — contas criadas a partir de 15/12/2020 Contas anteriores: 1 Load Balancer Micro (10 Mbps) Suporte a até 16 listeners e 1.024 backends Network Load Balancer # 1 NLB Always Free Até 50 listeners, 50 backend sets, 1.024 backends no total Site-to-Site VPN # Até 50 conexões IPSec VCN Flow Logs # 10 GB por mês de logs compartilhados com o serviço de Logging Observability \u0026amp; Management # Monitoring: 500 milhões de pontos de ingestão + 1 bilhão de pontos de consulta Application Performance Monitoring: 1.000 eventos de tracing e 10 execuções de Synthetic Monitor por hora Connector Hub: 2 conectores Always Free Notifications: 1 milhão de notificações HTTPS e 1.000 e-mails por mês Logging: incluído, compartilha os 10 GB mensais com VCN Flow Logs Console Dashboards: 100 dashboards por tenancy Email Delivery: 3.000 e-mails por mês Fleet Application Management: gerenciamento de lifecycle dos primeiros 25 recursos por mês Segurança # Vault: chaves criptográficas por software (ilimitadas) + 20 versões de chaves HSM + 150 secrets Bastion: acesso SSH restrito e temporário — gratuito para todos os tipos de conta Outros Serviços # Certificates: 5 CAs e 150 certificados Cluster Placement Groups: 10 a 50 grupos por região Resource Manager: 100 stacks, 100 templates, 100 configuration source providers, 2 jobs simultâneos Outbound Data Transfer: 10 TB por mês de tráfego de saída Dicas Importantes # Região home é obrigatória: recursos Always Free como block volume e instâncias só são gratuitos na região home da sua conta. Monitore seus limites: acesse Governance \u0026amp; Administration → Limits, Quotas and Usage no Console OCI para ver seus limites atuais. Upgrade não cancela o Always Free: se você fizer upgrade para conta paga, os recursos Always Free continuam gratuitos — você paga apenas pelo que usar além dos limites. Instâncias ociosas são recuperadas: mantenha suas instâncias com atividade mínima para evitar perda. Use Resource Manager para provisionamento rápido: o OCI templates permitem criar todo o conjunto Always Free em poucos minutos via Terraform. Conclusão # O Oracle Cloud Always Free é uma excelente opção para projetos pessoais, laboratórios de estudo e provas de conceito. Com instâncias AMD e ARM, banco de dados autônomo, 200 GB de armazenamento e 10 TB de transferência mensal, você tem poder computacional suficiente para rodar aplicações reais sem se preocupar com cobranças.\nNa EF-TECH, temos experiência em projetos na Oracle Cloud e podemos ajudar sua empresa a planejar e executar migrações para o OCI com foco em economia e boas práticas. Entre em contato para saber mais.\n","date":"19 junho 2026","externalUrl":null,"permalink":"/pt-br/blog/oracle-always-free/","section":"Soluções em Cloud Computing","summary":"O Oracle Cloud Infrastructure (OCI) oferece um conjunto generoso de recursos Always Free que incluem instâncias AMD e ARM, banco de dados autônomo, 200 GB de block storage, load balancer e muito mais. Veja tudo que você pode provisionar sem pagar nada.","title":"Oracle Cloud Always Free: recursos gratuitos para sempre","type":"pt-br"},{"content":"Oracle Cloud Infrastructure (OCI) provides one of the most generous Always Free programs among major cloud providers. Unlike trials that expire after 30 or 90 days, Always Free resources are available for the lifetime of your account in your tenancy\u0026rsquo;s home region.\nWhether you are running a personal project, building a proof of concept, or learning cloud computing, this guide covers every Always Free resource available.\nCompute # OCI offers two Always-Free compute options:\nVM.Standard.E2.1.Micro (AMD) # Processor: 1/8 OCPU AMD (with burst capability) Memory: 1 GB Networking: 1 VNIC with 1 public IP, up to 50 Mbps (internet) or 480 Mbps (intra-region) Images: Oracle Linux, Oracle Linux Cloud Developer, Ubuntu, CentOS Limit: up to 2 instances per account VM.Standard.A1.Flex (ARM — Ampere) # Processor: up to 2 OCPUs total (flexible: 1 instance with 2 OCPUs or 2 instances with 1 OCPU each) Memory: up to 12 GB total Networking: bandwidth and VNICs scale with OCPUs Images: Oracle Linux, Oracle Linux Cloud Developer, Ubuntu Limit: 1,500 OCPU hours and 9,000 GB-hours per month ⚠️ Idle instances may be reclaimed. If CPU is below 20%, network below 20%, and memory below 20% (A1 only) for 7 consecutive days, Oracle may stop the instance.\nStorage # Block Volume # 200 GB total combined boot and block volumes 5 concurrent volume backups Each instance\u0026rsquo;s boot volume uses 50 GB from this pool Always Free volumes must be in the home region Object Storage # 20 GB combined Standard, Infrequent Access, and Archive 50,000 monthly Object Storage API requests Database # Oracle Autonomous AI Database # 2 instances Always Free per tenancy 1 OCPU and 20 GB storage each Supported workloads: Transaction Processing, JSON Database, APEX Application Development, Lakehouse 20 concurrent sessions per database Oracle NoSQL Database # Up to 133 million reads per month Up to 133 million writes per month 3 tables with 25 GB each Oracle MySQL HeatWave # 1 standalone DB system with HeatWave 50 GB data storage + 50 GB backup storage Networking # Virtual Cloud Network (VCN) # Up to 2 VCNs per Free Tier tenancy IPv4 and IPv6 support Load Balancer # 1 Flexible Load Balancer (10 Mbps min/max) — tenancies created after Dec 15, 2020 Older tenancies: 1 Micro Load Balancer (10 Mbps) Up to 16 listeners and 1,024 backends Network Load Balancer # 1 NLB Always Free Up to 50 listeners, 50 backend sets, 1,024 backends Site-to-Site VPN # Up to 50 IPSec connections VCN Flow Logs # 10 GB per month shared with Logging service Observability \u0026amp; Management # Monitoring: 500 million ingestion + 1 billion retrieval data points Application Performance Monitoring: 1,000 tracing events and 10 Synthetic Monitor runs per hour Connector Hub: 2 Always Free connectors Notifications: 1 million HTTPS and 1,000 email notifications per month Logging: included, shares the 10 GB monthly pool with VCN Flow Logs Console Dashboards: 100 dashboards per tenancy Email Delivery: 3,000 emails per month Fleet Application Management: lifecycle management for the first 25 resources per month Security # Vault: unlimited software-protected keys + 20 HSM key versions + 150 secrets Bastion: restricted, time-limited SSH access — free for all account types Additional Services # Certificates: 5 CAs and 150 certificates Cluster Placement Groups: 10 to 50 per region Resource Manager: 100 stacks, 100 templates, 100 configuration source providers, 2 concurrent jobs Outbound Data Transfer: 10 TB per month of outbound traffic Important Tips # Home region required: Always Free resources like block volumes and compute instances are only free in your tenancy\u0026rsquo;s home region. Monitor your limits: Go to Governance \u0026amp; Administration → Limits, Quotas and Usage in the OCI Console. Upgrade preserves Always Free: upgrading to a paid account keeps all Always Free resources at no cost — you only pay for usage above the limits. Idle instances get reclaimed: keep your instances active to avoid losing them. Use Resource Manager for quick provisioning: OCI templates can deploy a full Always Free stack in minutes via Terraform. Conclusion # The Oracle Cloud Always Free tier is an excellent choice for personal projects, learning labs, and proof-of-concept work. With AMD and ARM compute instances, autonomous databases, 200 GB of storage, and 10 TB of monthly data transfer, you have enough resources to run real applications without worrying about costs.\nAt EF-TECH, we have hands-on experience with Oracle Cloud projects and can help your company plan and execute OCI migrations focused on cost savings and best practices. Get in touch to learn more.\n","date":"19 junho 2026","externalUrl":null,"permalink":"/en/blog/oracle-always-free/","section":"Cloud Computing Solutions","summary":"Oracle Cloud Infrastructure (OCI) offers a generous Always Free tier including AMD and ARM compute instances, autonomous databases, 200 GB of block storage, load balancers, and 10 TB of outbound data transfer per month.","title":"Oracle Cloud Always Free: unlimited free cloud resources","type":"en"},{"content":"EF-TECH selects, deploys, and manages open-source solutions for IT asset management and service desk. Our product portfolio combines the flexibility and cost savings of open source with the security and support of a team specialized in containerized infrastructure.\nOur Products # GLPI # GLPI is an open-source IT asset management and ITIL service desk software. EF-TECH offers containerized deployment via Docker and Kubernetes, with managed hosting and dedicated support.\nWireGuard # WireGuard is a modern, containerized, and secure corporate VPN. EF-TECH offers deployment via Docker with Alpine Linux, automated health checks, and production-ready monitoring.\nReady to get started? Contact us and schedule a consultation.\n","date":"19 junho 2026","externalUrl":null,"permalink":"/en/produtos/","section":"Cloud Computing Solutions","summary":"Discover the products EF-TECH offers, deploys, and manages for your IT infrastructure.","title":"Products","type":"en"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/categories/produtos/","section":"Categories","summary":"","title":"Produtos","type":"categories"},{"content":"A EF-TECH seleciona, implanta e gerencia soluções de software livre para gestão de ativos de TI e service desk. Nosso portfólio de produtos combina a flexibilidade e economia do open source com a segurança e o suporte de uma equipe especializada em infraestrutura containerizada.\nNossos Produtos # GLPI # GLPI é um software livre de gestão de ativos de TI e service desk ITIL. A EF-TECH oferece deploy containerizado via Docker e Kubernetes, com hosting gerenciado e suporte dedicado.\nWireGuard # WireGuard é uma VPN corporativa moderna, containerizada e segura. A EF-TECH oferece deploy via Docker com Alpine Linux, health check automatizado e monitoramento pronto para produção.\nPronto para começar? Fale conosco e agende uma consultoria.\n","date":"19 junho 2026","externalUrl":null,"permalink":"/pt-br/produtos/","section":"Soluções em Cloud Computing","summary":"Conheça os produtos que a EF-TECH oferece, implanta e gerencia para sua infraestrutura de TI.","title":"Produtos","type":"pt-br"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/rede/","section":"Tags","summary":"","title":"Rede","type":"tags"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/service-desk/","section":"Tags","summary":"","title":"Service-Desk","type":"tags"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/supabase/","section":"Tags","summary":"","title":"Supabase","type":"tags"},{"content":"O Supabase acaba de dar um passo enorme na integração entre bancos de dados e inteligência artificial: agora é um app oficial do ChatGPT. Isso significa que você pode conectar seus projetos Supabase e gerenciar toda a infraestrutura de banco de dados simplesmente descrevendo o que precisa em linguagem natural.\nCom o app do Supabase para ChatGPT, é possível executar consultas SQL, modificar schemas, fazer deploy de Edge Functions, gerenciar branches e diagnosticar problemas nos seus projetos sem sair da conversa com o ChatGPT.\nPeça para o ChatGPT verificar recomendações de segurança no seu projeto e corrigir eventuais problemas. Solicite uma alteração de schema e o ChatGPT executa. Faça deploy de uma Edge Function com um único prompt.\nO que é possível fazer # O app do Supabase para ChatGPT inclui 29 ferramentas divididas em cinco categorias principais:\nGerenciamento de banco de dados # Executar consultas SQL em bancos PostgreSQL Criar e modificar schemas de tabelas Listar tabelas e extensões instaladas Obter recomendações de segurança Operações de projeto # Listar e criar novos projetos Obter estimativas de custos Pausar e restaurar projetos Acessar logs em tempo real Branching e migrações # Criar branches de desenvolvimento Fazer merge de alterações Rebase e reset de branches Listar e aplicar migrações Edge Functions # Listar funções serverless Fazer deploy de novas funções Gerenciar funções existentes Documentação # Pesquisar na documentação do Supabase diretamente do ChatGPT Você também pode combinar o app com o recurso ChatGPT Projects para escopo de conversa a um projeto específico do Supabase. Basta definir a referência do projeto nas instruções uma vez, e todos os chats naquele projeto se conectam automaticamente ao banco de dados correto.\nPor que isso importa para desenvolvedores # Esta integração representa uma mudança de paradigma na forma como interagimos com bancos de dados. Em vez de alternar entre terminais, interfaces web e documentação, o desenvolvedor pode:\nReduzir atrito operacional — tarefas rotineiras como criar tabelas, rodar migrações ou verificar logs são resolvidas em segundos com linguagem natural Acelerar debugging — peça ao ChatGPT para analisar logs e sugerir correções sem sair do fluxo Democratizar o acesso ao banco — membros do time com menos familiaridade com SQL podem executar consultas e modificar dados com segurança Automatizar tarefas repetitivas — alterações de schema, deploy de functions e gerenciamento de branches viram comandos de voz ou texto Como começar a usar # Para começar a usar o app do Supabase no ChatGPT:\nAbra o diretório de apps no ChatGPT e procure por \u0026ldquo;Supabase\u0026rdquo; Acesse diretamente a página do app Autorize o ChatGPT a acessar sua organização no Supabase Pronto! Comece a gerenciar seus projetos com comandos em linguagem natural O app funciona em todos os planos do Supabase e em planos pagos do ChatGPT (Plus, Pro, Team e Enterprise).\nIntegração com MCP # O app do Supabase para ChatGPT é construído sobre o protocolo MCP (Model Context Protocol), o mesmo padrão aberto que permite que assistentes de IA se conectem a ferramentas e fontes de dados. Isso significa que a mesma infraestrutura de integração pode ser usada com outros assistentes como Claude, Cursor e VS Code.\nPara desenvolvedores que já utilizam o Supabase MCP server, a transição é natural — o ChatGPT agora é mais um cliente na lista de conectores suportados.\nConclusão # A chegada do Supabase como app oficial do ChatGPT marca um novo capítulo na forma como desenvolvemos e gerenciamos bancos de dados. A combinação de um backend-as-a-service open source com a interface conversacional do ChatGPT reduz barreiras técnicas e acelera o desenvolvimento.\nNa EF-TECH, acompanhamos de perto essas inovações para oferecer as melhores soluções em cloud computing e desenvolvimento para nossos clientes. Entre em contato para saber como podemos ajudar sua equipe a aproveitar o que há de mais moderno em infraestrutura e IA.\n","date":"19 junho 2026","externalUrl":null,"permalink":"/pt-br/blog/supabase-chatgpt-app/","section":"Soluções em Cloud Computing","summary":"Supabase se torna app oficial do ChatGPT com 29 ferramentas integradas para gerenciar bancos de dados, executar SQL, fazer deploy de Edge Functions e muito mais — tudo por meio de conversação com IA.","title":"Supabase agora é um app oficial do ChatGPT","type":"pt-br"},{"content":"Supabase has just taken a huge step in the integration between databases and artificial intelligence: it is now an official ChatGPT app. This means you can connect your Supabase projects and manage your entire database infrastructure simply by describing what you need in natural language.\nWith the Supabase ChatGPT app, you can execute SQL queries, modify schemas, deploy Edge Functions, manage branches, and troubleshoot your projects without leaving your conversation with ChatGPT.\nAsk ChatGPT to check security advisories on your project and fix any issues. Request a schema change and ChatGPT executes it. Deploy an Edge Function with a single prompt.\nWhat you can do # The Supabase ChatGPT app includes 29 tools divided into five main categories:\nDatabase management # Execute SQL queries on PostgreSQL databases Design and modify table schemas List tables and installed extensions Get security recommendations Project operations # List and create projects Get cost estimates Pause and restore projects Access real-time logs Branching and migrations # Create development branches Merge changes Rebase and reset branches List and apply migrations Edge Functions # List serverless functions Deploy new functions Manage existing functions Documentation # Search Supabase docs directly from ChatGPT You can also pair the app with ChatGPT Projects to scope a conversation to a specific Supabase project. Set your project reference in the project instructions once, and every chat in that project connects to the right database automatically.\nWhy this matters for developers # This integration represents a paradigm shift in how we interact with databases. Instead of switching between terminals, web interfaces, and documentation, developers can:\nReduce operational friction — routine tasks like creating tables, running migrations, or checking logs are resolved in seconds with natural language Accelerate debugging — ask ChatGPT to analyze logs and suggest fixes without leaving your flow Democratize database access — team members less familiar with SQL can safely execute queries and modify data Automate repetitive tasks — schema changes, function deploys, and branch management become voice or text commands Getting started # To start using the Supabase app in ChatGPT:\nOpen the app directory in ChatGPT and search for \u0026ldquo;Supabase\u0026rdquo; Go directly to the app listing page Authorize ChatGPT to access your Supabase organization You\u0026rsquo;re all set! Start managing your projects with natural language commands The app works on all Supabase plans and paid ChatGPT plans (Plus, Pro, Team, Enterprise).\nMCP Integration # The Supabase ChatGPT app is built on the MCP (Model Context Protocol), the same open standard that allows AI assistants to connect to tools and data sources. This means the same integration infrastructure can be used with other assistants like Claude, Cursor, and VS Code.\nFor developers already using the Supabase MCP server, the transition is natural — ChatGPT is now another client in the supported connectors list.\nConclusion # Supabase becoming an official ChatGPT app marks a new chapter in how we develop and manage databases. The combination of an open-source backend-as-a-service with ChatGPT\u0026rsquo;s conversational interface lowers technical barriers and accelerates development.\nAt EF-TECH, we closely follow these innovations to offer the best cloud computing and development solutions for our clients. Contact us to learn how we can help your team leverage the latest in infrastructure and AI.\n","date":"19 junho 2026","externalUrl":null,"permalink":"/en/blog/supabase-chatgpt-app/","section":"Cloud Computing Solutions","summary":"Supabase becomes an official ChatGPT app with 29 integrated tools for managing databases, executing SQL, deploying Edge Functions, and more — all through AI-powered conversation.","title":"Supabase Is Now an Official ChatGPT App","type":"en"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/vpn/","section":"Tags","summary":"","title":"Vpn","type":"tags"},{"content":"","date":"19 junho 2026","externalUrl":null,"permalink":"/tags/wireguard/","section":"Tags","summary":"","title":"Wireguard","type":"tags"},{"content":" WireGuard # WireGuard is a modern, high-performance VPN protocol that combines cutting-edge encryption with exceptional speed. EF-TECH offers a lightweight, containerized WireGuard solution built on Alpine Linux (~50MB), designed for enterprise environments demanding security, simplicity, and reliability. The project is maintained by our team on GitHub with images available on GitHub Container Registry (ghcr.io).\nEnterprise WireGuard VPN # The EF-TECH WireGuard solution is designed to meet the connectivity demands of enterprise environments:\nHigh performance with low latency Modern encryption based on Curve25519, ChaCha20, and Poly1305 Simple configuration and streamlined key management Stateful connection with mutual authentication Efficient routing with split tunneling support Ideal for remote access and network interconnection Containerized Deployment # EF-TECH\u0026rsquo;s containerized WireGuard deployment ensures lightness and portability for any environment:\nDocker image based on Alpine Linux (~50MB) Container with automatic restart (restart: unless-stopped) NET_ADMIN and SYS_MODULE capabilities for network and kernel management Optimized sysctl settings (ip_forward, ipv6.conf.all.forwarding) Graceful shutdown with signal handling (SIGTERM, SIGINT) Simplified deployment via Docker Compose Exposed ports: 51820/udp (VPN) and 8080/tcp (health check) Persistent volumes for configuration (./etc/:/etc/wireguard/) Environment variables: WG_CONF, WG_PRIVATE_KEY, WG_PUBLIC_KEY, WG_INTERFACE, PUID, PGID, TZ, SERVERURL, SERVERPORT, INTERNAL_SUBNET, PEERDNS Monitoring and Health Check # The solution includes integrated monitoring to ensure continuous service availability:\nHTTP endpoint on port 8080 for health verification Returns HTTP 200 when the service is operational Returns HTTP 503 when the service is unavailable Python wireguard_healthcheck.py script as health check server Ideal for integration with orchestrators and monitoring systems Ready for production environments with high availability requirements Key Management # Key management is automated to simplify operations and increase security:\nAutomatic private key generation via wg genkey Automatic public key derivation via wg pubkey Keys stored in persistent files: etc/privatekey and etc/publickey Interface configuration stored in etc/wg0.conf Support for manual key definition via environment variables (WG_PRIVATE_KEY, WG_PUBLIC_KEY) Architecture that allows key rotation without service interruption Repository # Source code, Dockerfile, docker-compose.yml, and full documentation are available in the official repository:\nRepository: https://github.com/eftechcombr/wireguard Images available on ghcr.io Docker Compose with cap_add, sysctls, volumes, and ports configured Entry scripts (entrypoint.sh) and health check (wireguard_healthcheck.py) Open-source license for enterprise use Interested in WireGuard for your company? Contact us for a personalized consultation.\n","date":"19 junho 2026","externalUrl":null,"permalink":"/en/produtos/wireguard/","section":"Cloud Computing Solutions","summary":"WireGuard is a modern, containerized, and secure corporate VPN. EF-TECH offers deployment via Docker with Alpine Linux, automated health checks, key management, and production-ready monitoring.","title":"WireGuard","type":"en"},{"content":" WireGuard # WireGuard é um protocolo VPN moderno e eficiente que combina criptografia de última geração com alto desempenho. A EF-TECH oferece uma solução containerizada e leve do WireGuard construída sobre Alpine Linux (~50MB), projetada para ambientes corporativos que exigem segurança, simplicidade e confiabilidade. O projeto é mantido pela nossa equipe no GitHub com imagens disponíveis no GitHub Container Registry (ghcr.io).\nVPN Corporativa WireGuard # A solução WireGuard da EF-TECH foi desenvolvida para atender as demandas de conectividade segura em ambientes corporativos:\nAlto desempenho com baixa latencia Criptografia moderna baseada em Curve25519, ChaCha20 e Poly1305 Configuração simples e gerenciamento simplificado de chaves Conexão stateful com autenticação mútua Roteamento eficiente com suporte a split tunneling Ideal para acesso remoto e interconexão de redes Deploy Containerizado # O deploy containerizado do WireGuard pela EF-TECH garante leveza e portabilidade para qualquer ambiente:\nImagem Docker baseada em Alpine Linux (~50MB) Container com reinicialização automática (restart: unless-stopped) Capacidades NET_ADMIN e SYS_MODULE para gerenciamento de rede e kernel Configurações de sysctl otimizadas (ip_forward, ipv6.conf.all.forwarding) Graceful shutdown com tratamento de sinais (SIGTERM, SIGINT) Deploy simplificado via Docker Compose Portas expostas: 51820/udp (VPN) e 8080/tcp (health check) Volumes persistentes para configuração (./etc/:/etc/wireguard/) Variaveis de ambiente: WG_CONF, WG_PRIVATE_KEY, WG_PUBLIC_KEY, WG_INTERFACE, PUID, PGID, TZ, SERVERURL, SERVERPORT, INTERNAL_SUBNET, PEERDNS Monitoramento e Health Check # A solução inclui monitoramento integrado para garantir a disponibilidade contínua do serviço:\nEndpoint HTTP na porta 8080 para verificação de saúde Retorna HTTP 200 quando o servico esta operacional Retorna HTTP 503 quando o servico esta indisponivel Script Python wireguard_healthcheck.py como servidor de health check Ideal para integração com orquestradores e sistemas de monitoramento Pronto para ambientes de produção com requisitos de alta disponibilidade Gerenciamento de Chaves # O gerenciamento de chaves é automatizado para simplificar a operação e aumentar a segurança:\nGeração automática de chave privada via wg genkey Derivação automática de chave pública via wg pubkey Chaves armazenadas em arquivos persistentes: etc/privatekey e etc/publickey Configuração da interface armazenada em etc/wg0.conf Suporte a definição manual de chaves via variáveis de ambiente (WG_PRIVATE_KEY, WG_PUBLIC_KEY) Arquitetura que permite rotação de chaves sem interrupção do serviço Repositorio # O código fonte, Dockerfile, docker-compose.yml e documentação completa estão disponíveis no repositório oficial:\nRepositorio: https://github.com/eftechcombr/wireguard Imagens disponiveis em ghcr.io Docker Compose com cap_add, sysctls, volumes e portas configuradas Scripts de entrada (entrypoint.sh) e health check (wireguard_healthcheck.py) Licença de código aberto para uso corporativo Interessado em WireGuard para sua empresa? Entre em contato para uma consultoria personalizada.\n","date":"19 junho 2026","externalUrl":null,"permalink":"/pt-br/produtos/wireguard/","section":"Soluções em Cloud Computing","summary":"WireGuard é uma VPN corporativa moderna, containerizada e segura. A EF-TECH oferece deploy via Docker com Alpine Linux, health check automatizado, gerenciamento de chaves e monitoramento pronto para produção.","title":"WireGuard","type":"pt-br"},{"content":"A migração para cloud deixou de ser uma tendência e se tornou uma necessidade competitiva. Em 2026, empresas que ainda mantém infraestrutura 100% on-premise enfrentam custos elevados, limitações de escalabilidade e riscos de segurança crescentes.\nAqui estão 5 benefícios fundamentais da migração para cloud:\n1. Redução de Custos # A maior vantagem do cloud é a mudança de CapEx (capital expenditure) para OpEx (operational expenditure). Em vez de investir em servidores físicos que envelhecem, você paga apenas pelo que usa.\nSem custo de hardware fisico Sem custo de manutenção de datacenter Pagamento por uso (pay-as-you-go) Otimização com reserved instances e spot instances 2. Escalabilidade Automatica # No modelo tradicional, escalar significa comprar e configurar novos servidores — processo que pode levar semanas. No cloud, escalonamento acontece em minutos, automaticamente, baseado na demanda real.\nAuto-scaling groups que crescem e diminuem conforme o trafego Serverless que escala para zero quando nao ha demanda Load balancing que distribui carga eficientemente Multi-regiao para atender usuarios globalmente 3. Segurança Aprimorada # Provedores de cloud investem bilhões em segurança anualmente — algo que pouquíssimas empresas conseguem replicar on-premise.\nCriptografia em transito e em repouso por padrao WAF e proteção contra DDoS integradas IAM com controle granular de acesso Conformidade com LGPD, ISO 27001, SOC 2 4. Agilidade e Velocidade # Cloud permite que equipes de desenvolvimento entreguem features mais rapido, com infraestrutura disponivel em minutos via codigo.\nInfrastructure as Code (Terraform, CloudFormation) Pipelines de CI/CD nativos Ambientes de desenvolvimento e teste em minutos Deploy continuo com rollback automatico 5. Inovação Contínua # Provedores de cloud lançam novos serviços constantemente — IA, machine learning, IoT, edge computing. Migrando para cloud, sua empresa tem acesso imediato a essas tecnologias.\nServicos de IA e ML gerenciados Bancos de dados gerenciados (vetores, grafos, series temporais) Edge computing para baixa latencia Integração nativa com ferramentas de observabilidade Conclusão # A migração para cloud em 2026 não é mais uma questão de \u0026ldquo;se\u0026rdquo;, mas de \u0026ldquo;quando\u0026rdquo; e \u0026ldquo;como\u0026rdquo;. Com o parceiro certo, a transição pode ser suave, segura e com retorno sobre investimento rápido.\nNa EF-TECH, ajudamos empresas a planejar e executar migrações para cloud com minimização de riscos e maximização de resultados. Entre em contato para uma avaliação gratuita.\n","date":"15 janeiro 2026","externalUrl":null,"permalink":"/pt-br/blog/primeiro-post/","section":"Soluções em Cloud Computing","summary":"Redução de custos, escalabilidade, segurança, agilidade e inovação: confira 5 motivos para migrar para cloud em 2026.","title":"5 benefícios da migração para cloud em 2026","type":"pt-br"},{"content":"Cloud migration is no longer a trend — it\u0026rsquo;s a competitive necessity. In 2026, companies still running 100% on-premise infrastructure face high costs, scalability limitations, and growing security risks.\nHere are 5 key benefits of cloud migration:\n1. Cost Reduction # The biggest advantage of the cloud is shifting from CapEx (capital expenditure) to OpEx (operational expenditure). Instead of investing in physical servers that degrade over time, you pay only for what you use.\nNo physical hardware costs No datacenter maintenance costs Pay-as-you-go pricing Optimization with reserved and spot instances 2. Auto Scaling # In the traditional model, scaling means buying and configuring new servers — a process that can take weeks. In the cloud, scaling happens in minutes, automatically, based on real demand.\nAuto-scaling groups that grow and shrink based on traffic Serverless that scales to zero when there\u0026rsquo;s no demand Load balancing for efficient traffic distribution Multi-region to serve users globally 3. Enhanced Security # Cloud providers invest billions in security annually — something very few companies can replicate on-premise.\nEncryption in transit and at rest by default Integrated WAF and DDoS protection IAM with granular access control Compliance with LGPD, ISO 27001, SOC 2 4. Agility and Speed # Cloud allows development teams to deliver features faster, with infrastructure available in minutes via code.\nInfrastructure as Code (Terraform, CloudFormation) Native CI/CD pipelines Dev/test environments in minutes Continuous deployment with automatic rollback 5. Continuous Innovation # Cloud providers launch new services constantly — AI, machine learning, IoT, edge computing. By migrating to the cloud, your company gets immediate access to these technologies.\nManaged AI and ML services Managed databases (vector, graph, time-series) Edge computing for low latency Native integration with observability tools Conclusion # Cloud migration in 2026 is no longer a question of \u0026ldquo;if,\u0026rdquo; but \u0026ldquo;when\u0026rdquo; and \u0026ldquo;how.\u0026rdquo; With the right partner, the transition can be smooth, secure, and with fast return on investment.\nAt EF-TECH, we help companies plan and execute cloud migrations with minimized risk and maximized results. Contact us for a free assessment.\n","date":"15 janeiro 2026","externalUrl":null,"permalink":"/en/blog/primeiro-post/","section":"Cloud Computing Solutions","summary":"Cost reduction, scalability, security, agility, and innovation: check out 5 reasons to migrate to the cloud in 2026.","title":"5 Benefits of Cloud Migration in 2026","type":"en"},{"content":"","date":"15 janeiro 2026","externalUrl":null,"permalink":"/tags/azure/","section":"Tags","summary":"","title":"Azure","type":"tags"},{"content":"","date":"15 janeiro 2026","externalUrl":null,"permalink":"/tags/cloud/","section":"Tags","summary":"","title":"Cloud","type":"tags"},{"content":" Cloud Computing # EF-TECH delivers complete cloud computing solutions, from initial migration to ongoing infrastructure management. We work with AWS, Google Cloud Platform, and Microsoft Azure.\nCloud Migration # Planning and execution of on-premise to cloud infrastructure migration, with minimized downtime and business continuity assurance.\nCloud readiness assessment Migration strategy (lift-and-shift, replatforming, refactoring) Phased execution with rollback Post-migration validation and optimization Cloud Architecture # Design of scalable, resilient, and cost-optimized architectures following best practices for each provider.\nMulti-region and multi-zone architecture High availability and disaster recovery Serverless (Lambda, Cloud Functions, Azure Functions) Microservices and containers (Kubernetes, ECS, GKE, AKS) Auto Scaling # Configuration of auto-scaling so your infrastructure grows and shrinks based on demand, optimizing costs without compromising performance.\nAuto-scaling groups (EC2, GCP MIG, Azure VMSS) Custom metric-based scaling Load balancing and traffic distribution Cost optimization with spot instances and committed use discounts Cost Optimization # Continuous cloud spending analysis with identification of idle resources, right-sizing, and reserved instances / savings plans recommendations.\nCost dashboard by team/project Budget alerts and anomaly detection Instance right-sizing Storage lifecycle management Managed Services # Complete management of your cloud infrastructure with 24/7 monitoring, patching, backups, and dedicated technical support.\nInterested? Contact us for a free infrastructure assessment.\n","date":"15 janeiro 2026","externalUrl":null,"permalink":"/en/servicos/cloud-computing/","section":"Cloud Computing Solutions","summary":"Migration, architecture, and cloud infrastructure management with AWS, GCP, and Azure. Auto-scaling, serverless, and cost optimization.","title":"Cloud Computing","type":"en"},{"content":" Cloud Computing # A EF-TECH entrega soluções completas de cloud computing, desde a migração inicial até a gestão contínua da sua infraestrutura. Trabalhamos com AWS, Google Cloud Platform e Microsoft Azure.\nMigração para Cloud # Planejamento e execução de migração de infraestrutura on-premise para cloud, com minimização de downtime e garantia de continuidade do negócio.\nAvaliação de prontidão para cloud Estratégia de migração (lift-and-shift, replatforming, refatoração) Execução por fases com rollback Validação e otimização pós-migração Arquitetura Cloud # Desenho de arquiteturas escalaveis, resilient e custo-otimizadas, seguindo as melhores praticas de cada provedor.\nArquitetura multi-regiao e multi-zona Alta disponibilidade e disaster recovery Serverless (Lambda, Cloud Functions, Azure Functions) Microservicos e containers (Kubernetes, ECS, GKE, AKS) Escalonamento Automatico # Configuração de auto-scaling para que sua infraestrutura cresça e diminua conforme a demanda, otimizando custos sem comprometer performance.\nAuto-scaling groups (EC2, GCP MIG, Azure VMSS) Escalonamento baseado em metricas customizadas Load balancing e traffic distribution Cost optimization com spot instances e committed use discounts Otimização de Custos # Análise contínua de gastos em cloud com identificação de recursos ociosos, right-sizing e recomendações de reserved instances / savings plans.\nDashboard de custos por equipe/projeto Alertas de budget e anomalias Right-sizing de instancias Lifecycle management de storage Serviços Gerenciados # Gestão completa da sua infraestrutura cloud com monitoramento 24/7, patching, backups e suporte técnico dedicado.\nInteressado? Entre em contato para uma avaliação gratuita da sua infraestrutura.\n","date":"15 janeiro 2026","externalUrl":null,"permalink":"/pt-br/servicos/cloud-computing/","section":"Soluções em Cloud Computing","summary":"Migração, arquitetura e gestão de infraestrutura cloud com AWS, GCP e Azure. Escalonamento automático, serverless e otimização de custos.","title":"Cloud Computing","type":"pt-br"},{"content":"","date":"15 janeiro 2026","externalUrl":null,"permalink":"/tags/firewall/","section":"Tags","summary":"","title":"Firewall","type":"tags"},{"content":"","date":"15 janeiro 2026","externalUrl":null,"permalink":"/tags/gcp/","section":"Tags","summary":"","title":"Gcp","type":"tags"},{"content":"","date":"15 janeiro 2026","externalUrl":null,"permalink":"/tags/lgpd/","section":"Tags","summary":"","title":"Lgpd","type":"tags"},{"content":" Cloud Security # Your infrastructure and data security is our priority. EF-TECH implements multiple protection layers to ensure your cloud environment is resilient against threats.\nFirewall and WAF # Configuration and management of network firewalls and Web Application Firewalls to protect against application-layer attacks.\nFirewall rules (Security Groups, NACLs) WAF with OWASP Top 10 rules DDoS protection Rate limiting and geo-blocking SIEM (Security Information and Event Management) # Centralization and correlation of security logs for proactive threat detection and incident response.\nLog collection from multiple sources Real-time event correlation and alerts Security and compliance dashboards Automated incident response LGPD Compliance # Adaptation of your cloud infrastructure to meet Brazilian General Data Protection Law (LGPD) requirements.\nPersonal data mapping Access controls and encryption Retention and deletion policies Compliance audit and documentation Penetration Testing # Controlled attack simulations to identify vulnerabilities before they can be exploited.\nCloud infrastructure pentest Web application pentest Security configuration analysis Technical + executive report with recommendations Backup and Disaster Recovery # Backup and disaster recovery strategy to ensure business continuity in any scenario.\nAutomated multi-region backup Periodic restoration testing Application-defined RTO and RPO Documented disaster recovery plan Zero Trust Architecture # Implementation of the Zero Trust model, where every access is verified regardless of origin.\nIdentity and Access Management (IAM) Multi-factor authentication (MFA) Network micro-segmentation Least privilege access Protect your business. Schedule a security assessment with our team.\n","date":"15 janeiro 2026","externalUrl":null,"permalink":"/en/servicos/seguranca/","section":"Cloud Computing Solutions","summary":"Complete protection for your cloud environment: firewall, WAF, SIEM, LGPD, pentest, and backup with disaster recovery.","title":"Security","type":"en"},{"content":" Segurança Cloud # A segurança da sua infraestrutura e dos seus dados é nossa prioridade. A EF-TECH implementa camadas múltiplas de proteção para garantir que seu ambiente cloud seja resiliente contra ameaças.\nFirewall e WAF # Configuração e gestão de firewalls de rede e Web Application Firewalls para proteção contra ataques de camada de aplicação.\nFirewall rules (Security Groups, NACLs) WAF com regras OWASP Top 10 Proteção contra DDoS Rate limiting e geo-blocking SIEM (Security Information and Event Management) # Centralização e correlação de logs de segurança para detecção proativa de ameaças e resposta a incidentes.\nColeta de logs de multiplas fontes Correlação de eventos e alertas em tempo real Dashboards de segurança e compliance Resposta a incidentes automatizada Conformidade com LGPD # Adequação da sua infraestrutura cloud aos requisitos da Lei Geral de Proteção de Dados (LGPD).\nMapeamento de dados pessoais Controles de acesso e criptografia Políticas de retenção e exclusão Auditoria e documentação de compliance Testes de Invasao (Pentest) # Simulação de ataques controlados para identificar vulnerabilidades antes que sejam exploradas.\nPentest de infraestrutura cloud Pentest de aplicacoes web Análise de configuração de segurança Relatório técnico + executivo com recomendações Backup e Disaster Recovery # Estratégia de backup e recuperação de desastres para garantir a continuidade do seu negócio em qualquer cenário.\nBackup automatizado multi-regiao Testes de restauração periódicos RTO e RPO definidos por aplicação Disaster recovery plan documentado Zero Trust Architecture # Implementação do modelo Zero Trust, onde cada acesso é verificado independente de origem.\nIdentity and Access Management (IAM) Multi-factor authentication (MFA) Microsegmentação de rede Least privilege access Proteja seu negócio. Agende uma avaliação de segurança com nossa equipe.\n","date":"15 janeiro 2026","externalUrl":null,"permalink":"/pt-br/servicos/seguranca/","section":"Soluções em Cloud Computing","summary":"Proteção completa para seu ambiente cloud: firewall, WAF, SIEM, LGPD, pentest e backup com disaster recovery.","title":"Segurança","type":"pt-br"},{"content":"EF-TECH offers a complete portfolio of services to ensure your cloud infrastructure is performant, secure, and cost-effective. We work with the leading cloud platforms on the market.\nOur Services # Cloud Computing # Migration, architecture, and infrastructure management on AWS, Google Cloud, and Azure. Auto-scaling, serverless, and cost optimization.\nSecurity # Complete protection for your environment: firewall, WAF, SIEM, LGPD compliance, penetration testing, and backup with disaster recovery.\nDevOps and Automation # CI/CD pipeline, Infrastructure as Code with Terraform, container management with Kubernetes and Docker, deployment automation, and monitoring.\nManaged Infrastructure # 24/7 monitoring, incident management, auto-scaling, continuous cost optimization, and detailed performance reports.\nGLPI # Open-source IT asset management and ITIL service desk. Containerized deployment via Docker and Kubernetes, with managed hosting and dedicated support.\nReady to get started? Contact us and schedule a consultation.\n","date":"15 janeiro 2026","externalUrl":null,"permalink":"/en/servicos/","section":"Cloud Computing Solutions","summary":"Explore the cloud computing services EF-TECH offers to transform your infrastructure.","title":"Services","type":"en"},{"content":"","date":"15 janeiro 2026","externalUrl":null,"permalink":"/categories/servicos/","section":"Categories","summary":"","title":"Servicos","type":"categories"},{"content":"A EF-TECH oferece um portifolio completo de servicos para garantir que sua infraestrutura de cloud seja performatica, segura e custo-efetiva. Trabalhamos com as principais plataformas de cloud do mercado.\nNossos Servicos # Cloud Computing # Migração, arquitetura e gestão de infraestrutura em AWS, Google Cloud e Azure. Escalonamento automático, serverless e otimização de custos.\nSegurança # Proteção completa para seu ambiente: firewall, WAF, SIEM, conformidade com LGPD, testes de invasão e backup com recuperação de desastres.\nDevOps e Automação # Pipeline de CI/CD, Infrastructure as Code com Terraform, gestão de containers com Kubernetes e Docker, automação de deploy e monitoramento.\nInfraestrutura Gerenciada # Monitoramento 24/7, gestão de incidentes, escalonamento automático, otimização contínua de custos e relatórios de performance detalhados.\nGLPI # Software livre de gestão de ativos de TI e service desk ITIL. Deploy containerizado via Docker e Kubernetes, com hosting gerenciado e suporte dedicado.\nPronto para começar? Fale conosco e agende uma consultoria.\n","date":"15 janeiro 2026","externalUrl":null,"permalink":"/pt-br/servicos/","section":"Soluções em Cloud Computing","summary":"Conheça os serviços de cloud computing que a EF-TECH oferece para transformar sua infraestrutura.","title":"Serviços","type":"pt-br"},{"content":"","date":"15 janeiro 2026","externalUrl":null,"permalink":"/tags/siem/","section":"Tags","summary":"","title":"Siem","type":"tags"},{"content":" About EF-TECH # EF-TECH is a company specialized in cloud computing solutions, dedicated to transforming the performance and security of IT infrastructures. We work with the leading cloud platforms — AWS, Google Cloud, and Microsoft Azure — delivering results that directly impact your business success.\nOur Mission # To democratize access to cutting-edge cloud technology by offering solutions that combine performance, security, and cost-effectiveness. We believe every company, regardless of size, deserves a modern, scalable, and secure infrastructure.\nWhat Sets Us Apart # Certified team: Professionals with certifications across major cloud platforms (AWS, GCP, Azure) Results-driven: We don\u0026rsquo;t sell technology for technology\u0026rsquo;s sake — we deliver measurable value Personalized service: Each client receives a plan tailored to their reality Full transparency: Detailed reports, clear metrics, and constant communication Dedicated support: Service via GLPI portal with defined SLA Areas of Expertise # Cloud Migration: Planning and execution of secure, zero-downtime migrations Security and Compliance: Complete protection with LGPD compliance focus DevOps and Automation: CI/CD pipelines, Infrastructure as Code, Kubernetes Managed Infrastructure: 24/7 monitoring and continuous optimization Who We Serve # We serve companies of all sizes — from startups to established enterprises — looking to modernize their infrastructure, reduce operational costs, and increase data security.\nReady to transform your infrastructure? Get in touch and let\u0026rsquo;s talk.\n","externalUrl":null,"permalink":"/en/sobre/","section":"Cloud Computing Solutions","summary":"EF-TECH is a company specialized in cloud computing, focused on performance, security, and cost-effectiveness for your infrastructure.","title":"About EF-TECH","type":"en"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":" Contact EF-TECH # We\u0026rsquo;re ready to help transform your infrastructure. Choose the most convenient channel:\nSupport Portal # For ticket submission and tracking, access our GLPI portal:\nGLPI Portal: https://glpi.eftech.com.br Email # Contact: contato@eftech.com.br Social Media # WhatsApp: https://wa.me/5585988037625 GitHub: https://github.com/eftechcombr YouTube: https://youtube.com/@eftechcombr Business Hours # Monday to Friday: 09:00 - 18:00 Critical 24/7 support for SLA clients Need help with your cloud infrastructure? Open a ticket on our support portal.\n","externalUrl":null,"permalink":"/en/contato/","section":"Cloud Computing Solutions","summary":"EF-TECH support and service channels. Access our GLPI portal, GitHub, YouTube, or email.","title":"Contact","type":"en"},{"content":" Fale com a EF-TECH # Estamos prontos para ajudar a transformar sua infraestrutura. Escolha o canal de atendimento mais conveniente:\nPortal de Suporte # Para abertura de chamados e acompanhamento de tickets, acesse nosso portal GLPI:\nPortal GLPI: https://glpi.eftech.com.br Email # Contato: contato@eftech.com.br Redes Sociais # WhatsApp: https://wa.me/5585988037625 GitHub: https://github.com/eftechcombr YouTube: https://youtube.com/@eftechcombr Horario de Atendimento # Segunda a Sexta: 09h00 - 18h00 Suporte critico 24/7 para clientes com SLA Precisa de ajuda com sua infraestrutura cloud? Abra um chamado em nosso portal de suporte.\n","externalUrl":null,"permalink":"/pt-br/contato/","section":"Soluções em Cloud Computing","summary":"Canais de atendimento e suporte da EF-TECH. Acesse nosso portal GLPI, GitHub, YouTube ou email.","title":"Contato","type":"pt-br"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":" Sobre a EF-TECH # A EF-TECH é uma empresa especializada em soluções de cloud computing, dedicada a transformar a performance e a segurança de infraestruturas de TI. Atuamos com as principais plataformas de cloud do mercado — AWS, Google Cloud e Microsoft Azure — entregando resultados que impactam diretamente o sucesso do seu negócio.\nNossa Missao # Democratizar o acesso a tecnologia cloud de ponta, oferecendo soluções que combinam performance, segurança e custo-benefício. Acreditamos que toda empresa, independentemente do porte, merece uma infraestrutura moderna, escalável e segura.\nO que nos diferencia # Equipe certificada: Profissionais com certificações nas principais plataformas de cloud (AWS, GCP, Azure) Foco em resultados: Não vendemos tecnologia pela tecnologia — entregamos valor mensurável Atendimento personalizado: Cada cliente recebe um plano adaptado à sua realidade Transparência total: Relatórios detalhados, métricas claras e comunicação constante Suporte dedicado: Atendimento via portal GLPI com SLA definido Áreas de atuação # Migração para Cloud: Planejamento e execução de migrações seguras e sem downtime Segurança e Compliance: Proteção completa com foco em LGPD DevOps e Automação: Pipelines de CI/CD, Infrastructure as Code, Kubernetes Infraestrutura Gerenciada: Monitoramento 24/7 e otimização contínua Quem atendemos # Atendemos empresas de diversos portes — de startups a empresas estabelecidas — que buscam modernizar sua infraestrutura, reduzir custos operacionais e aumentar a segurança de seus dados.\nPronto para transformar sua infraestrutura? Entre em contato e vamos conversar.\n","externalUrl":null,"permalink":"/pt-br/sobre/","section":"Soluções em Cloud Computing","summary":"A EF-TECH é uma empresa especializada em cloud computing, focada em performance, segurança e custo-benefício para sua infraestrutura.","title":"Sobre a EF-TECH","type":"pt-br"}]