[{"categories":null,"date":"March 17, 2026","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/your-platform-is-not-ready-for-ai/","section":"blog","summary":"Do you know which parts of your platform are actually ready for AI agents — and which aren\u0026rsquo;t?\nIn this 30-minute LinkedIn Live, Tomasz Cholewa walks through the gaps he sees most often - and what it takes to close them before something goes wrong in production.\nHe\u0026rsquo;s going to talk about the three things that matter, and the failure patterns that happen when they\u0026rsquo;re missing.\nWho this is for CTOs and VPs of Engineering at funded companies who are already thinking about AI agents — and want an honest picture of where their platform stands.\n🎥 Watch the recording here.\n","tags":["cloudnative","platformengineering","ai","platformstrategy"],"title":"Your Platform Is Not Ready for AI Agents. Here's How to Fix That. (video)"},{"categories":["articles"],"date":"February 25, 2026","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/7-lessons-from-writing-ai-agents/","section":"articles","summary":"I decided to bet on AI agents and started writing them a long time ago. There are many reasons, but the main one is pure laziness. I\u0026rsquo;ve always wanted to automate things, and that\u0026rsquo;s why I became a DevOps engineer in the first place.\nFor me it\u0026rsquo;s a natural progression in my career that also feeds my innate curiosity, which led me from Linux systems through the cloud and containers to Kubernetes and Cloud Native technologies.\nFor now, I cannot reveal what my first agent will do, but I\u0026rsquo;ll share a few lessons from my perspective. As someone focused on Platform Engineering, my view on AI agents is skewed toward improving platforms for all kinds of apps (including the \u0026ldquo;vibe-coded\u0026rdquo; ones).\n1. Why it\u0026rsquo;s not that hard (anymore) I remember when I started digging into AI agents over a year ago. Back then the most popular frameworks were LangChain, LangGraph, and CrewAI. I even managed to write a simple agent, but it wasn\u0026rsquo;t something I enjoyed. It wasn\u0026rsquo;t easy either. These frameworks work, but they are too complex and have a steep learning curve.\nThere is one thing I do differently this time. I focus mostly on requirements and architecture, and let the code be written by AI. That\u0026rsquo;s right — I realized I won\u0026rsquo;t be as good in Python as LLMs, but I can use my thinking skills to instruct what I want and how I want it to work.\nThis realization changed my approach. I spend most of my time analyzing the features of my agent and how to implement them with an AI framework.\nHow do I want to use sessions? What should the agent remember and store in its memory? What design patterns should I use to make it flexible and extensible? What tools should I use and how should I provide them? What parts should be sent to the LLM and what should be handled by deterministic code? How do I evaluate it? These are the questions I try to answer. Testing is especially important when developing an agent.\n2. Why testing is crucial There\u0026rsquo;s a huge challenge with AI agents. When they use LLMs the outcome can be nondeterministic. That\u0026rsquo;s the nature of LLMs and it\u0026rsquo;s the challenge that needs to be addressed when you implement your own agent. It\u0026rsquo;s better to be tested well, because otherwise you\u0026rsquo;ll get disappointing results.\nThings get even more complicated when you realize there are so many LLMs and they can interpret your prompts and the results from the tools very differently. That\u0026rsquo;s why testing is critical. At first I started testing as a part of the regular test suite — integration and end-to-end tests that included calls to LLMs.\nFortunately, there\u0026rsquo;s a better way. Many frameworks offer built-in evaluation methods. For example, the Google ADK framework has a decent evaluation. This makes the tests so much more robust, predictable and easier to maintain.\nThe AI agent is just another piece of software. Maybe a bit different, expected to perform amazing things with a bit of LLM \u0026ldquo;magic\u0026rdquo;, but it\u0026rsquo;s still software. Every good software deserves proper tests so don\u0026rsquo;t forget about this crucial part and use evaluation frameworks if possible.\n3. Why freedom is actually bad for agents The media and less technical people imagine that AI is a panacea for all problems and is so powerful that it can solve every old problem much better. That\u0026rsquo;s only partially true, and there are a couple of caveats.\nTo create efficient AI agents you need to become a manager. That\u0026rsquo;s right — you need to start thinking about how to best instruct the agent to do the work. It requires shifting perspective from focusing purely on technology to focusing on providing clear goals and the right tools.\nWith AI agents there\u0026rsquo;s also one important ingredient — the freedom you give the agent. As I\u0026rsquo;ve learned, this is very critical to success and to costs.\nMy first agents had a lot of freedom. I was focused on writing proper prompts and letting them use the tools I thought were necessary for the tasks I had defined. I soon discovered it wasn\u0026rsquo;t working as I thought it would.\nThe tools I provided were too generic. I let the agent provide many of the necessary parameters, which often led to failed attempts to use the tools correctly. That generated too many calls to the LLM and too many errors before getting things right — and I wasted a lot of tokens.\nI trusted LLMs too much and forgot about their nondeterministic nature. For the tasks I defined, I should have done things differently — and I did.\nA much better approach is to limit the freedom of AI agents. I do it in two ways. First, the prompt: I define clear goals (what to do), restrictions (what NOT to do) and examples (here\u0026rsquo;s HOW to do it).\nThe second is to limit how tools are used. Instead of giving unlimited access to an API, I use Pydantic models to describe inputs and outputs in a deterministic way. I also write wrappers for functions used as tools to validate requests before they reach their destinations.\nThis approach is much faster, more reliable, and cheaper.\nLLMs are smart, but I don\u0026rsquo;t rely on them too much. I let them connect the dots, but it\u0026rsquo;s better to control which dots they can use.\n4. Spend your tokens wisely Tokens are the new currency in the AI world. You can very quickly spend a huge amount of them by letting the LLM think extensively about the problem you want it to solve, especially if it\u0026rsquo;s defined in an ambiguous way. This reminds me of how cloud providers want you to use as many services as possible, even if they offer features you don\u0026rsquo;t really need.\nThat\u0026rsquo;s understandable when you want to solve a single problem and receive results without further interaction with the LLM. With AI agents it\u0026rsquo;s a different story. They are designed to run continuously and process requests in unknown quantities. Thus they need to be efficient and frugal.\nI use a couple of techniques to address this challenge. First is the restricted-freedom approach and the careful use of tools I described above. Next is measuring the tokens used by the agent and improving prompts to be more specific. After all, you can\u0026rsquo;t control something you don\u0026rsquo;t measure.\nAnother technique to decrease costs is caching. Most models support it, with or without explicit configuration. Caching can save tokens, especially for agents that perform repeatable tasks with various inputs.\nTools generate a significant portion of token costs due to the data sent to LLMs. When I make API requests in tool calls, I try to limit the amount of data returned. If I can limit the scope of a query, less data is sent and fewer tokens are used. Often this is achieved by selecting only the fields significant for the agent.\nI prefer less-cluttered data and use a more detailed view only when it\u0026rsquo;s really needed (for example, via a different tool or with proper prompt instructions).\n5. Run own LLM or use services? When I bought my Macbook M4 Pro a year ago I knew I wanted to run my own LLMs locally and that\u0026rsquo;s why I added 48 GB of RAM. I was excited when I first ran the Llama 3 model with Ollama and I was full of hope that it would allow me to use my own hardware for developing AI agents.\nNot all models available for Ollama support tools required by agents, but that\u0026rsquo;s not the only issue — there are other limitations. I tested DeepSeek-R1, GLM-4.7, Qwen-3 and many more. They all failed. Why?\nThe models with open weights that you can run locally are simply not as capable as proprietary hosted LLMs. I was limited by 48 GB of memory, but still ran versions with over 30 billion parameters. What I needed wasn\u0026rsquo;t an omnipotent model, but one that would properly use the tools I provided — and I faced a huge dissapointment.\nMaybe I should have written better prompts or tuned things more, but this experience discouraged me from relying on local models. They were also very slow. I can accept slow responses, but the results were disappointing.\nSo yes, for now I would stick with LLMs from large providers such as OpenAI, Google, Microsoft or Anthropic. It looks like they are all fighting for attention and building the new customer base for LLM services, and often they charge you less than they actually spend on running them.\nAccording to my experiments they are better, faster, and more reliable. The value provided by AI agents is significant enough that the cost of using hosted LLMs is often justified.\nMaybe this will change in the future, but for more complex agents I would stick with proprietary, smarter LLMs for now.\n6. Which framework to choose? I tried to write my first agents over a year ago. I used LangChain and LangGraph which were the most mature frameworks back then. It wasn\u0026rsquo;t a pleasant experience. These frameworks are very generic and have a steep learning curve.\nMaybe if I had spent more time experimenting and had been more persistent I could have done more. But I wasn\u0026rsquo;t — I gave up and thought it was too complex and that I wasn\u0026rsquo;t good enough.\nThen I came across n8n (there\u0026rsquo;s also an issue with its licensing for commercial products), but soon I realized it\u0026rsquo;s not something I\u0026rsquo;m interested in. It looked to me like an agentic workflow rather than a framework for creating autonomous agents.\nI want my agents to run in the background. I don\u0026rsquo;t need a fancy UI. I may add one if needed, but the core value is in the way the agent handles tasks on its own.\nAt the time of writing, OpenClaw is the hottest AI bot on the planet. I decided to give it a try as it looked impressive.\nI managed to run it for a few tasks and it is very versatile, mostly thanks to the growing number of skills it uses to interact with many services. It\u0026rsquo;s cool if you want a personal assistant. I guess that\u0026rsquo;s its biggest selling point — automate tedious tasks and impress your friends.\nWhen you write an autonomous AI agent, or create a team of such agents, you need a proper framework. For my use cases — handling tasks from DevOps and Platform Engineering — I needed a well-documented, stable, and extensible framework in Python. My agents run mostly on Kubernetes and use many APIs to perform tasks.\nHere are my top 3 frameworks at the moment:\nPydantic AI Google ADK Microsoft Autogen Each of them has pros and cons. Most try to persuade you to use services provided by their creators or make it less frictionless to use other options (e.g., long-term memory).\nFortunately they all support the use of tools and MCP servers. This allows my agents to interact with the services I want to manage or use to perform complex tasks.\nThese are the most important features I need and use:\nLong term memory Support for MCP Support for most popular LLMs (including local run with Ollama) Excellent documentation (preferably with llms.txt) Support for evaluation Support for A2A 7. Software development practices FTW I\u0026rsquo;m not a pro when it comes to software development. I\u0026rsquo;ve spent my time building skills in the Platform Engineering area. It allowed me to use my innate curiosity to analyze and understand how many systems work, but somehow I didn\u0026rsquo;t need to.\nThe emergence of AI and its fantastic capabilities to write code in almost any language has changed how I approach building agents. I need to build them like regular software, but focus on software development practices. LLMs will take care of the code; my job is to make sure that code is testable, extensible, and easy to understand for both me and future improvements made by AI.\nSo instead of polishing my programming skills, I turned my attention to architecture. My prompts include design patterns like factory, dependency injection, and single-responsibility principles.\nAs my codebase grows, these standards help me build mental models of the system. It\u0026rsquo;s my responsibility to understand component relationships, data flow, and ideas for enhancements and fixes. This is fundamental — you can skip low-level coding, but not the higher-level architectural layer.\nWhat I also realized is how important data modeling is for AI agents. My agents benefit from well-defined structures for the data they operate on.\nThey are written in Python and I use Pydantic to provide strict field definitions. It works very well.\nThanks to validation rules, my agents receive well-defined input formats and clear expectations for outputs. That makes it easier to pass information between LLMs and tools.\nConclusion AI agents are the next level for DevOps and Platform Architects like me. The capabilities of LLMs can be used to create autonomous agents that maintain and improve platforms for any kind of app.\nThis will also make it easier to enforce the practices we\u0026rsquo;ve been preaching about, such as zero-trust architecture, chaos engineering, and full observability. It\u0026rsquo;s never been easier to implement them, and now we have excellent tools to help.\nI predict platforms that don\u0026rsquo;t embrace AI will be outpaced by those enhanced with AI tools, especially autonomous agents. That\u0026rsquo;s why I spend my time preparing and being part of this inevitable future.\nThis article was written by a human. AI was only used to correct typos and errors.\n","tags":["platformengineering","devops","ai","aiagents"],"title":"7 lessons from writing AI agents for platforms"},{"categories":["articles"],"date":"February 5, 2026","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/what-is-gitops/","section":"articles","summary":"Is GitOps just another buzzword? We already have DevOps, DevSecOps, MLOps, and lately even LLMOps or AIOps. It’s easy to feel overwhelmed by all these terms. However, GitOps is one of those concepts that actually changes how we work for the better.\nIn this article, I want to explain what GitOps is, why it has become so popular, and what it really means for your day-to-day operations.\nWhat is GitOps? At its simplest, GitOps is a set of practices that uses Git as the single source of truth for your infrastructure and applications.\nIf you are using Kubernetes, you are likely already writing \u0026ldquo;declarative\u0026rdquo; configurations—files that describe what you want (e.g., \u0026ldquo;I want three copies of this app running\u0026rdquo;) rather than how to do it.\nGitOps takes this a step further by putting these files in a Git repository and using automation to make sure the live system always matches those files.\nYou can break it down into two parts:\nThe \u0026ldquo;Git\u0026rdquo; part: A Git repository is the central hub. It holds all the configuration for your apps and infrastructure. The \u0026ldquo;Ops\u0026rdquo; part: Automated tools constantly compare what is in Git with what is actually running. If they don\u0026rsquo;t match, the tools fix it. Why is everyone talking about it? GitOps didn\u0026rsquo;t just appear out of nowhere. It is the next logical step in the evolution of Infrastructure as Code (IaC).\nIn the past, we used scripts to set up servers. Then we moved to tools like Terraform to define infrastructure as code. GitOps completes this journey by providing a full lifecycle management framework that is versioned and controlled entirely from your repositories.\nThe Concrete Benefits of GitOps Why should you care? Here are five reasons why teams are moving to this model:\n1. Faster Delivery With GitOps, making a change is as simple as opening a Pull Request (PR). Once the PR is merged, automation takes care of the rest.\nExample: A developer pushes code to a feature branch. This triggers a build that creates a new container image. A PR to the staging environment is automatically updated with the new image version, and a preview environment is ready for testing within minutes. 2. Stronger Security Git provides a built-in audit trail. You know exactly who changed what and when. You can also enforce \u0026ldquo;guardrails\u0026rdquo; by requiring code reviews and signed commits.\nExample: You can set a policy that only approved PRs can be merged into the main branch. If someone tries to manually change a setting in the cluster, the GitOps engine will see it as \u0026ldquo;drift\u0026rdquo; and revert it to the secure version defined in Git. 3. Higher Reliability and Self-Healing If a human makes a mistake or a system component fails, the GitOps engine detects the \u0026ldquo;drift\u0026rdquo; between the desired state (in Git) and the actual state (on the platform).\nExample: If a configuration file in your cluster gets corrupted or misconfigured, the GitOps controller (like Argo CD or Flux) will automatically re-apply the correct version from Git. 4. Improved Scalability Managing one cluster is easy. Managing one hundred is hard. GitOps makes multi-cluster management much simpler through templating.\nExample: You can change a single \u0026ldquo;values\u0026rdquo; file in a Helm chart and have that change propagate to 100 different clusters simultaneously with a single PR. 5. Developer-Centric Experience Developers don\u0026rsquo;t need to learn complex infrastructure tools or have direct access to production clusters. They can stay within their familiar environment: Git. This speeds up feedback loops and makes the team more agile.\nHow it Works: The GitOps Engine To make GitOps work, you need a \u0026ldquo;GitOps Engine\u0026rdquo; like Argo CD or Flux.\nThink of this engine as an automated assistant that runs a continuous loop:\nPull: It watches your Git repository for any changes. Compare: It checks the current state of your cluster. Sync: If there is a difference (drift), it automatically updates the cluster to match Git. It’s like having an automated process running kubectl apply every time you save a file in your repository.\nWhat should you put in your GitOps Repo? In a modern platform, nearly everything can be defined as code. Your repositories should reflect:\nApplications: What versions are running and what configurations they use. Clusters: Which apps should run on which clusters. Security: Access labels, network rules, and audit policies. Platform Services: Databases, logging tools, and observability add-ons. Promotion: How code moves from dev to staging to production (managed via branches or tags). It Sounds Easy\u0026hellip; Is there a Catch? While the principle is simple, implementing it perfectly can be challenging.\nComplexity: Tools like Argo CD are powerful but require expertise to set up and secure properly. Platform Knowledge: You still need to understand Kubernetes. GitOps doesn\u0026rsquo;t replace that; it just changes how you interact with it. The \u0026ldquo;100% Myth\u0026rdquo;: Achieving \u0026ldquo;100% GitOps\u0026rdquo; is hard. Legacy software, organizational silos, and lack of specialized skills often mean the transition takes time. Practical Implementation: The Deployment Factory While understanding the theory of GitOps is essential, seeing it in a production-ready framework helps solidify these concepts.\nIf you\u0026rsquo;re looking to implement these patterns, check out my Kubernetes Deployment Factory. It is a complete, end-to-end delivery solution that integrates GitLab CI and Argo CD, providing a standardized way to manage application lifecycles, preview environments, and secure promotions across clusters.\nConclusion: It\u0026rsquo;s About Principles, Not Tools The most important thing to remember is that GitOps is not about a specific tool. It’s not about Argo CD or Flux. It is a principle: keeping everything as code.\nBy moving your \u0026ldquo;source of truth\u0026rdquo; to Git, you build platforms that are more professional, secure, and easier to manage. In my upcoming articles, I’ll dive deeper into how to set these tools up and the best ways to structure your repositories.\nRemember: \u0026ldquo;Everything as code\u0026rdquo; is the foundation of modern, professional platforms.\n","tags":["platformengineering","gitops","devops"],"title":"What is GitOps?"},{"categories":null,"date":"January 27, 2026","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/its-not-that-easy/","section":"blog","summary":" It\u0026rsquo;s not as easy as we thought it would be. AI changed a lot, but we\u0026rsquo;re still going to struggle with the weakest link in the process: the human loop.\nWe are the reason why these processes exists - with or without AI. Now more than ever, companies need better judgement to limit the impact of the bureaucracy.\nIt won\u0026rsquo;t disappear as it often includes necessary the means to keep company assets secure, maintain governance and align processes with the strategy.\nDo you think AI is going to change that as well or is it going to be the bottleneck regardless of how much AI is used to create new products?\n#betterjudgement #ai #platformstrategy #platformengineerting hashtag#devops\n","tags":["cloudnative","platformengineering","ai","platformstrategy"],"title":"It's not that easy"},{"categories":null,"date":"January 27, 2026","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/why-we-created-the-innoventis-foundation/","section":"blog","summary":"We are excited to announce that we have started a new non-profit organization called the Innoventis Foundation. We created it because we want to give back to the tech community and help IT in Poland grow.\nWhat We Want to Do We have a few main goals for the foundation:\nSupporting Cloud Native events: We love the Cloud Native community. We already helped organize KCD Warsaw 2025. Now that we are an official foundation, we plan to help even more with the 2026 event. Building better tools with AI: We want to help develop tools that use AI to make platform engineering easier and better. Helping the Polish IT scene: We want to support events and projects in Poland that promote new technology. We want to make sure Polish IT stays modern and innovative. Being a non-profit organization is quite a challenge, but we hope to gather funds and support from the community to make it possible. We are also looking for volunteers to help us with the foundation so please let us know if you are interested.\nA Personal Step for Me Being the chairman of this foundation is a big step for me. It is a great way for me to grow and learn how to lead an organization. I am naturally an introvert, so I am looking forward to meeting new people. I hope to build good relationships with other tech fans and volunteers who care about the same things I do.\nI\u0026rsquo;ve always wanted to contribute in other ways than just working on code, providing commercial services like training or consulting. I believe that this foundation will allow me to do that. I also want to give back to the community, as I have been helped by many people in the past.\nThe Big Challenge The hardest part will be time. I have to find a good balance between my regular job, my personal life, and all the work for the foundation. It won’t be easy, but I expect to learn a lot and have plenty of fun along the way.\nJoin Us! We are just starting, and we would love for you to follow our journey.\nCheck out our website: innoventis.pl/en/ Follow us on LinkedIn: Innoventis Foundation Let’s build something great together and help others grow!\n","tags":["cloudnative","platformengineering"],"title":"Why we created the Innoventis Foundation"},{"categories":["articles"],"date":"December 3, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/5-challenges-ai-platform-engineering/","section":"articles","summary":"AI has become an indispensable tool for software development. I can\u0026rsquo;t imagine working without an LLM-powered assistant anymore. However, after months of intensive use, I\u0026rsquo;ve noticed something important: AI is great for writing applications, but it struggles with platform engineering code.\nHere\u0026rsquo;s why platform engineering presents unique challenges for AI, and what we need to address to make it truly effective.\nThe Fundamental Difference Software engineering has been around for decades. We have countless design patterns or practices like Domain Driven Design. We have well-established best practices documented in books, blogs, and courses.\nWe have massive amounts of training data from millions of repositories. This makes it relatively straightforward for AI to generate application code. Software developers have been learning to write code in various ways, but using a relatively small number of patterns.\nPlatform engineering is different. We have too few established design patterns. There are myriad ways to create environments, design CI/CD pipelines, manage deployments, and make systems flexible.\nWe have limited training data compared to application development. This fundamental difference creates several challenges when using AI for platform engineering.\nChallenge 1: Lack of Established Patterns Platform engineering lacks the rich ecosystem of design patterns that application development enjoys. While software engineering has well-documented patterns like MVC, Factory, or Observer, platform engineering is still evolving. AI models are trained on patterns, and without clear, established patterns, they struggle to generate consistent, high-quality platform code.\nEvery organization approaches platform engineering differently, making it harder for AI to learn from existing codebases. What works for one team\u0026rsquo;s GitOps setup might be completely wrong for another.\nWhen I ask AI to create a Helm Chart, it often generates something generic that doesn\u0026rsquo;t align with my specific GitOps approach. I need to teach it our patterns, not just copy-paste from documentation.\nChallenge 2: Context Is Everything (And Expensive) Platform engineering requires deep understanding of your specific architecture, your processes and workflows, your tooling patterns and conventions, and your organizational constraints. AI needs extensive context to generate platform code that fits your environment, and large contexts are expensive. I burned through $20 in less than two weeks!\nWithout proper context, AI generates code that looks correct but doesn\u0026rsquo;t match your patterns. I\u0026rsquo;ve tried GitHub Copilot, Cursor, and Antigravity. The built-in knowledge isn\u0026rsquo;t enough.\nThey need to be fed with detailed architecture descriptions, process documentation, pattern examples specific to your organization, and tool usage conventions like which ArgoCD Application options to use or how to structure GitLab CI templates.\nContext consumption is a real concern. You need to limit the number of files in context, use summaries instead of full files when possible, choose models with smaller contexts when appropriate, and leverage MCP (Model Context Protocol) for more efficient context management. The companies behind these models aren\u0026rsquo;t incentivized to help you pay less, so learning to manage context effectively becomes a critical skill.\nChallenge 3: Teaching AI Your Specific Patterns Platform engineering is highly contextual. What works for one organization might be wrong for another. AI needs to learn your specific patterns, not just general best practices.\nGeneric AI suggestions often don\u0026rsquo;t align with your GitOps approach. You need to teach AI about your Helm Chart structure, specify which ArgoCD Application and ApplicationSet options to use, define how to construct reusable GitLab CI templates, how to align with Kubernetes Policies, and many more rules to follow.\nI maintain an AGENTS.md file with such rules and patterns. This is absolutely critical! Without this documentation, AI agents would generate code that doesn\u0026rsquo;t match my organization\u0026rsquo;s specific approach to platform engineering.\nMy workflow has evolved into a structured process that ensures quality while leveraging AI effectively:\nRequest the change: I ask the agent to make a specific change, whether it\u0026rsquo;s creating a new Helm Chart, modifying an ArgoCD Application, or updating a GitLab CI template. Agent implementation: The agent thinks through the problem, considers the context I\u0026rsquo;ve provided, and implements the change based on the patterns in AGENTS.md. Review and verification: I carefully review what the agent created, checking for hallucinations, outdated knowledge, or opportunities to simplify the solution. This is where domain expertise is crucial - I need to know if the approach is correct and optimal. Request corrections: If something isn\u0026rsquo;t right, I provide feedback and ask for corrections. The agent learns from this feedback and adjusts its approach. Document new patterns: When I discover a better way to do something or identify a pattern that should be followed, I add it as a new rule for future reference. Update AGENTS.md: Finally, I ask the agent to update the AGENTS.md file with the new rule or pattern. I\u0026rsquo;m so lazy, I don\u0026rsquo;t even touch it manually anymore 😄. This iterative process ensures that the agent gets better over time and that my platform engineering patterns are consistently applied across all changes.\nThe difference is striking. Cursor \u0026ldquo;absorbed\u0026rdquo; the rules and started working well almost from the beginning. Antigravity didn\u0026rsquo;t respect them and eventually gave up, asking for help (sic!).\nThis shows how crucial it is for agents to actually read and apply instructions. The quality of your instructions directly impacts the quality of AI\u0026rsquo;s output.\nChallenge 4: MCP Ecosystem Is Still Immature Model Context Protocol (MCP) is critical for AI agents to interact with real systems, but the ecosystem is still in its infancy. MCP servers are essential for agents to access tools and services, yet many are incomplete or unstable.\nSome tools are locked behind expensive licenses - GitLab\u0026rsquo;s official MCP server requires higher-tier licenses, for example. Community alternatives often lack features or break unexpectedly.\nI built my own MCP server for OCI registries because nothing suitable existed. The GitLab MCP server I was using had issues and wasn\u0026rsquo;t fixed.\nI switched to another one, but it can\u0026rsquo;t perform merges. All my Git operations went through MCP, showing how critical these servers are.\nThe MCP ecosystem needs time to mature. We need stable, feature-complete servers for common tools. Until then, sometimes using commands directly works better than MCP, though MCP should be superior with proper elicitation features that allow agents to better understand available options before taking action.\nChallenge 5: AI Is a Force Multiplier, Not a Replacement AI can\u0026rsquo;t replace platform engineering knowledge. It\u0026rsquo;s a powerful assistant, but it requires supervision, verification, and someone who understands the system. AI often proposes overly complicated solutions when simpler ones exist.\nIt can make mistakes with syntax, outdated patterns, or wrong approaches. Without domain knowledge, you can\u0026rsquo;t verify if the agent\u0026rsquo;s work is correct. It\u0026rsquo;s like working with a junior engineer who needs constant teaching and correction.\nYes, you can sleep soundly - AI won\u0026rsquo;t be managing platforms independently anytime soon. It needs oversight and someone who understands the system.\nBut no, if you want to stay relevant - without understanding Kubernetes, Linux, containers, Helm, Git, and other platform fundamentals, you can\u0026rsquo;t verify what the agent does. AI is already replacing junior positions, similar to what happened in software development.\nAI is an excellent force multiplier when you understand the platform yourself, can verify and correct AI\u0026rsquo;s work, know when to simplify AI\u0026rsquo;s overly complex suggestions, and use it to speed up repetitive tasks while focusing on architecture and decisions. Instead of hours spent on tedious tasks, you can focus on the bigger picture.\nThe Path Forward The platform engineering community needs to develop and document more design patterns that AI can learn from. This might involve creating pattern libraries for common platform engineering scenarios, documenting GitOps patterns and best practices, and sharing reusable templates and conventions. The more patterns we establish, the better AI will become at platform engineering tasks.\nFine-tuning models on your specific patterns could be the next step. Instead of constantly providing context, a fine-tuned model would already understand your Helm Chart structure, ArgoCD Application patterns, GitLab CI template conventions, and GitOps workflows. This could be the breakthrough that makes AI truly effective for platform engineering.\nDespite the challenges, start using AI for platform engineering today. Test different editors and models. Learn how to work with AI effectively.\nThis is the moment to get in and figure out how to make it work for your specific needs. The landscape is changing rapidly, and those who learn to work with AI now will have a significant advantage.\nConclusion AI for platform engineering is awesome, but it\u0026rsquo;s not magic. The challenges are real: lack of established patterns compared to application development, context requirements that are both extensive and expensive, the need to teach AI your specific patterns and conventions, an immature MCP ecosystem that needs time to stabilize, and AI as a force multiplier rather than a replacement for platform engineering knowledge.\nThe key is understanding that platform engineering requires a different approach to AI than application development. We need better patterns, better context management, and better tools. But most importantly, we need platform engineers who understand their systems deeply enough to guide and verify AI\u0026rsquo;s work.\nIf you want to leverage AI for platform engineering, start now. Experiment, learn, and contribute to building the patterns and tools that will make AI truly effective for our field.\nThe future of platform engineering will be shaped by those who figure out how to make AI work effectively, not by those who wait for it to become perfect.\n","tags":["ai","platformengineering","gitops","devops"],"title":"5 Challenges of Using AI for Platform Engineering"},{"categories":null,"date":"November 27, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/138/","section":"newsletter-archive","summary":"Wsiąkłem. W pracę. I oczywiście, że coraz intensywniej zacząłem używać AI. Teraz nie wyobrażam sobie pracy bez jakiegoś LLMa.\nCzy to dlatego, że jestem leniwy? Z pewnością! Do tego jestem też ciekawy jak to się wszystko potoczy. Niewątpliwie zmiany już są widoczne na rynku pracy - zwolnienia, przetasowania i optymalizacje.\nDzisiaj opiszę Ci jak wygląda praktyczne zarządzanie platformami przy użyciu AI. A jeśli szukasz okazji na Black Friday to info o nich znajdziesz na końcu ⬇️.\nJak wykorzystuję AI do zarządzania platformami Wszystko zaczyna się od tego, że cała platforma jest w kodzie - wszystko zarządzane przez GitOps. To nie jest opcjonalne, to jest fundament. Bez tego nie ma mowy o sensownym wykorzystaniu AI do zarządzania platformą.\nMój proces podzieliłem na dwa etapy:\nEtap 1 - Zarządzanie z czatu w IDE z AI\nTo jest to, co robię teraz na co dzień. Zamiast ręcznie edytować pliki, uruchamiać komendy i sprawdzać status, po prostu rozmawiam z agentem w IDE.\nKluczowe jest tutaj wykorzystanie MCP (Model Context Protocol) - standardu, który pozwala agentom korzystać z narzędzi i serwisów. Napisałem nawet własny serwer MCP do OCI, bo brakowało takiego rozwiązania.\nTo pokazuje, jak ważne są te komponenty - bez nich agent nie ma dostępu do rzeczywistych systemów. Więcej o moim projekcie związanym z AI i zarządzaniem platformami możesz przeczytać w tym artykule.\nEtap 2 - Agenty działające na platformie\nTo jest przyszłość, nad którą pracuję. Agenty działające bezpośrednio na platformie (jako pody w klastrze Kubernetes), które odpowiadają za:\nkoordynację aktualizacji sprawdzanie kodu w repo GitOps (buildy na PR) optymalizację kosztową automatyczne reagowanie na problemy To jeszcze nie jest gotowe, ale widzę tu ogromny potencjał.\nJakich narzędzi używam?\nGłównie IDE z wbudowanymi agentami AI. Próbowałem różnych:\nCursor - bardzo spoko, fajne usystematyzowanie rules i instrukcji. To był game-changer dla mnie. VS Code z GitHub Copilot - mnie nie przekonał, brakowało mi spójności w podejściu. Efekty były gorsze niż w przypadku Cursora, nawet w wersji płatnej. Antigravity - wydany niedawno, za darmo to przewaga, dobry model, ale u mnie się gubił. Jeszcze nad nim popracuję. Windsurf, Zed i inne - trochę próbowałem, może wrócę do nich w przyszłości. Moje wnioski z dotychczasowej pracy Po kilku miesiącach intensywnego używania AI do zarządzania platformami, mam już sporo obserwacji:\nGitOps jest konieczny - to oczywista oczywistość\nBez GitOps nie ma mowy o sensownym wykorzystaniu AI. Agent musi mieć dostęp do kodu, który opisuje stan platformy. Bez tego nie może nic zrobić. To nie jest opcjonalne.\nJeśli chcesz dowiedzieć się więcej o GitOps, zapraszam do poprzednich newsletterów i odcinków podcastu, gdzie szczegółowo o tym opowiadałem.\nContext pożera pieniądze jak szalony\nFirmy od modeli będą bogate. Moje $20 \u0026ldquo;wydałem\u0026rdquo; w niecałe 2 tygodnie!\nTrzeba ograniczać spożycie i nauczyć się jak to robić. Duże konteksty wysyłane do modeli LLM są drogie, więc warto:\nograniczać ilość plików w kontekście używać podsumowań zamiast pełnych plików wybierać modele z mniejszymi kontekstami, gdy to możliwe korzystać z MCP, które może być bardziej efektywne niż wrzucanie wszystkiego do kontekstu Jeszcze się tego uczę, bo firmom od modeli nie zależy, abym płacił mniej :)\nSerwery MCP są krytycznym składnikiem, ale\u0026hellip;\nSą w powijakach. Standard się rozwija - to super! Każdy chce coś napisać (i kto to mówi 😉).\nPrzykładem jest serwer MCP do GitLaba - oficjalny jest używany tylko dla wyższych licencji. Ten, którego używałem, miał ostatnio problemy i nie doczekałem się na rozwiązanie.\nZaskoczyło mnie, że wszystkie zmiany w Git szły po MCP - to pokazuje, jak ważne są te serwery. W końcu użyłem innego, ale nie ma wszystkich tooli - np. nie może zrobić merge.\nTo pokazuje, że ekosystem MCP jest jeszcze młody i potrzebuje czasu na stabilizację, aby można było znaleźć solidne serwery do naszych potrzeb.\nKomendy mogą zastąpić MCP!\nCzasem agent zamiast użyć narzędzi z MCP wykonuje komendy i daje radę. Jak jest błąd, dobrze zna składnię, pięknie pisze złożone komendy.\nPrzy izolowanym środowisku z dobrą konfiguracją to\u0026hellip; może wystarczyć!\nALE MCP ma być lepsze, szczególnie że ma funkcje pytania o szczegóły (elicitation - niewiele jeszcze implementuje). To pozwoli agentom lepiej zrozumieć dostępne opcje przed wykonaniem akcji.\nAgenty z IDE korzystające z web dają radę\nBez tego radziłyby sobie gorzej. Szukają dokumentacji raczej niż specyfikacji - to mnie zaskoczyło.\nCzyli dostęp do internetu jest konieczny, aby taka praca była lepsza. Agent musi móc sprawdzić aktualną dokumentację, znaleźć przykłady i zrozumieć najlepsze praktyki.\nKrytyczny element - instrukcje\nMam plik AGENTS.md, gdzie opisuję reguły. To jest absolutnie kluczowe!\nNowy flow mojej pracy wygląda tak:\nProszę agenta o zmianę Agent myśli i wprowadza zmianę Ja tą zmianę sprawdzam - czy nie zahalucynował, czy nie ma przestarzałej wiedzy, czy da się lepiej Proszę o poprawki Wprowadzam nową regułę na przyszłość Proszę o uaktualnienie pliku AGENTS.md (Jestem tak leniwy, że sam już tego nie tykam 😄) Gigantyczna różnica - Cursor \u0026ldquo;łyknął\u0026rdquo; reguły i zaczął niemalże od początku dobrze, a Antigravity nie respektował i się poddał (tak! napisał na końcu, aby mu pomóc\u0026hellip;).\nTo pokazuje, jak ważne jest, aby agent faktycznie czytał i stosował instrukcje. Te już są po naszej stronie i bez nich praca jest o wiele bardziej czasochłonna.\nTo zdecydowanie force-multiplier\nNiestety wciąż czasem muszę poprawiać pracę agenta - złe reguły, rozwiązania z innych wersji, błędy składni itp.\nGdybym nie wiedział jak to może być zrobione (mniej więcej), to agent często by nie dał rady lub błądził wysyłając coraz większy context do LLM. Często proponuje też zbyt skomplikowane rozwiązania - sam wiem, że da się prościej i łatwiej.\nI dlatego to jest doskonały wspomagacz - nie zastępuje wiedzy, ale pozwala działać szybciej i efektywniej. Zamiast godzin spędzonych na żmudnych zadaniach, mogę skupić się na architekturze i decyzjach.\nCzy możemy spać spokojnie? Tak, póki co tak - to jeszcze nie etap, że AI będzie ogarniać platformę samodzielnie. Potrzebuje nadzoru, weryfikacji i kogoś, kto rozumie system.\nNie, jeśli chcesz liczyć się w tej branży - bez wiedzy o tym jak działa Kubernetes, Linux, kontenery, Helm, Git i inne elementy nowoczesnego stacku, AI już zastępuje pozycje juniora, podobnie jak przy programowaniu.\nJeśli nie rozumiesz podstaw, nie możesz weryfikować tego, co robi agent. A weryfikacja jest kluczowa - agent może zrobić coś, co wydaje się poprawne, ale w rzeczywistości jest błędne lub nieoptymalne.\nChcesz wykorzystać AI? Zaczynaj używać już teraz, testuj edytory i modele, nawet jak to się zmienia. To jest moment, kiedy warto wejść i nauczyć się, jak z tym pracować.\nOferta Black Friday Ja również przygotowałem coś specjalnego na tę okazję, szczególnie dla tych, co chcą się rozwijać.\nSpecjalna oferta do końca piątku - sprawdź na stronie https://edu.cloudowski.com.\n","tags":["devops","platformengineering","gitops","ai"],"title":"Newsletter #138 - Jak zarządzać platformami z AI"},{"categories":null,"date":"November 6, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/ai-ready-platform-checklist/","section":"articles","summary":"The promise of AI agents running your Kubernetes platform is huge: faster deployments, instant bug fixes, and massive optimization savings.\nBut before you hand over the controls, you have to ask a tough question: Is your infrastructure even ready to be managed?\nAs an architect who designs these advanced systems, I know the difference between a platform that can use AI and one that will thrive with it. Most current setups are dangerous blind spots waiting to happen.\nAre You Missing Out on Massive AI Benefits Because of These Problems? AI agents promise a revolution, but only if your environment speaks their language.\nIf you can’t answer \u0026ldquo;Yes\u0026rdquo; to these questions, you are missing out on real AI benefits:\nPerformance: Are your systems currently tracking deep application metrics so AI can easily see if its optimization changes actually made things faster? Or are you stuck guessing? Safety \u0026amp; Speed: Can an AI agent propose a complex infrastructure change via a controlled code review process that gets approved automatically if it passes all safety tests? Compliance: When an agent makes a change, is that change instantly logged, reviewable, and reversible in a way that meets strict audit rules? Data Security: If an agent accidentally deletes data, do you have automated, tested systems in place (beyond simple backups) to recover every byte instantly? Context: Does your AI know why you configured that system the way you did, or does it just see the code and potentially undo crucial business logic? If you are worried about these gaps, you are right to be concerned. These structural failures will block AI benefits and expose you to huge risks.\nGet the Step-by-Step Plan to Unlock True AI Power I’ve compiled my proven strategy into a clear, sequential 10-Step Checklist for architects who are serious about adopting autonomous management safely.\nDon\u0026rsquo;t wait for the problems to appear. Get the roadmap now.\nSign up below to instantly receive the complete 10-Step AI-Ready Platform Checklist straight to your inbox.\nLearn exactly how to build the foundation that lets AI deliver massive value, safely.\nGet the checklist ","tags":["ai","devops","platformengineering","kubernetes"],"title":"10-Step AI-Ready Platform Checklist"},{"categories":null,"date":"October 28, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/11-times-cheaper/","section":"blog","summary":"Am I stingy or thrifty? I refused to pay over 550pln (~130EUR) for new Airpods after the battery in my old ones depleted.\nI\u0026rsquo;ve already paid over 100pln to fix them a few months ago. Now I\u0026rsquo;ve decided that\u0026rsquo;s enough. What did I do instead?\nI\u0026rsquo;ve bought myself brand new earphones for less than 50pln. That\u0026rsquo;s right - over 11 times cheaper. Not two, not five - 1️⃣1️⃣ times cheaper!\nOf course, they are not as fancy, but they work. I only use them for listening to audiobooks before going to sleep, so I don\u0026rsquo;t care about the sound quality - which is quite good by the way - or microphones. They are good enough.\nJust to be clear, I own a Macbook and an iPhone. I see the value in the convenience of using them, and I pay a premium for it. However, they are not 11 times more expensive than their alternatives. I don\u0026rsquo;t need to boost my social status by wearing AirPods all the time. I like using things that work, and I\u0026rsquo;m willing to pay more when it\u0026rsquo;s worth it. Not this time, though.\nAm I the only one who thinks this is just another example of how we are being fooled?\n#GoodEnough #PointOfDiminishingReturns\n","tags":["personal"],"title":"11 times cheaper"},{"categories":null,"date":"October 23, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/why-organizing-kcd-warsaw-2025-was-not-that-easy/","section":"blog","summary":"When we opened our KCD Warsaw 2025 conference, I told a joke on stage that was actually true:\n“You think Kubernetes is hard? Try organizing your own KCD conference.”\nIndeed, this has been an interesting and challenging adventure. It’s not as easy and simple as it might look.\nHere are three reasons why it was sometimes difficult:\n🔵 We are volunteers with day jobs All KCD conferences are supported by CNCF and are non-profit events. In most cases, they are organized by a group of volunteers.\nWe put a lot of energy and time into preparing our KCD, all while managing our day jobs and other responsibilities. Sometimes we had to skip meetings, postpone ideas, or even abandon them due to lack of time.\nThere are no tangible incentives when organizing a KCD conference. All we had was our passion and energy, which are precious and limited resources we had to manage carefully.\n🔵 Non-profit does not mean careless about money Yes, it’s a non-profit conference, which means we had to raise money just to cover our expenses.\nThis didn’t make it easier. We still had to manage our budget, be frugal, and deal with uncertainty. Our suppliers didn’t care if we were non-profit—it was just business for them.\nLearning how to balance our cash flow was one of the most challenging aspects of organizing the conference, especially since no one on our team had ever been responsible for finances before.\n🔵 Little Experience. It was our first KCD, and for most of us, the first conference we had ever organized. We are technical people—engineers and architects—with little or no experience in this, so we had to learn as we went.\nFor me personally, it was very gratifying to extend my skills beyond my technical expertise, but it was still a challenge. Getting sponsors, venue, catering, sales, marketing, finances, booking speakers’ dinner, and after-party—we had little experience and prior knowledge. But we did it anyway. If you have your “why,” you can find the “hows” and “whats.” There was plenty of good stuff too. Here are my top three things that helped us:\n🟢 Support from CNCF. Our conference was supported by CNCF. We received some financial aid, but more importantly, we got guidelines and templates. These were very helpful, as they answered many questions and provided a scaffolding for the conference.\nWe also used tools provided by CNCF. We really enjoyed working with Sessionize for managing talks, and we used Bevy to maintain our site and sales. The latter was somewhat challenging, but we managed to learn to use it quite efficiently.\n🟢 Kubernetes and CNCF. Trust is crucial. Kubernetes and CNCF are well-known brands, which made it easier for us to find sponsors and attract people to our conference.\nThere are quite a few IT conferences in Poland, but none are so focused on the Cloud Native ecosystem. The support from CNCF was a major factor and a sort of assurance that this would be something special. And indeed it was!\n🟢 Energy and passion. The magic ingredient of our conference was the energy and passion of my co-organizers. It was our fuel that helped us get through all the ups and downs—and there were a few.\nMost of us had never met before we formed the group. It was sometimes challenging, yet rewarding, to get to know each other better. And the final reward was the day of the conference and the amazing feedback we got from people!\nVideo Here\u0026rsquo;s a short video that shows the result of our hard work:\n","tags":["kubernetes","conference"],"title":"Why organizing KCD Warsaw 2025 was not that easy"},{"categories":null,"date":"October 2, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/137/","section":"newsletter-archive","summary":"Każdy ma swoje dziwactwa. Ja na przykład jestem dziwny, bo piszę dokumentację. No dobra, dużo osób pisze i nie jest tak dziwna. Ja piszę, bo\u0026hellip; to lubię!\nMam wrażenie, że to pewna część mnie, która lubi spisywać, aby lepiej rozumieć. Kilka lat temu znalazłem potwierdzenie tego w teście Gallupa - cecha/talent Input jest u mnie dość wysoko.\nA dlaczego o tym dzisiaj piszę? Bo okazuje się, że słowo pisane jest jeszcze ważniejsze niż wcześniej.\nPisanie pozostanie Są nadal ludzie, którzy spisują swoje przemyślenia i doświadczenia. Dzięki temu wciąż mamy mnóstwo książek i ciekawych publikacji.\nJa należę do tych, co lubią konkrety, a nie lanie wody i dlatego od jakiegoś czasu posiadam własną subskrypcję O\u0026rsquo;Reilly. Czytam skondensowaną wiedzę i karmię mój umysł, aby miał nad czym pracować.\nMyślę coraz intensywniej nad napisaniem własnej książki, ale to melodia przyszłości 🤫.\nSkoro czytasz ten newsletter, to też należysz do tych, co wciąż cenią sobie słowo pisane - możesz teraz poklepać się po ramieniu i pogratulować, bo czytanie jest coraz mniej popularne.\nA jaki jest powód, że słowo pisane jest tak ważne? Oczywiście to AI, a dokładniej LLMy. Ktoś musi karmić modele kreatywnymi treściami, bo same nic nie wymyślą.\nDoszło do tego, że twórcy modeli AI muszą wypłacać olbrzymie odszkodowania autorom książek. Najcenniejsza wiedza jest właśnie w książkach i najwidoczniej 1.5 tryliona dolarów to wciąż niewielka cena za wartość, jaką dały te treści modelom LLM firmy Anthropic.\nSam tekst w postaci kodu ma też olbrzymie znaczenie. Dlatego też jestem takim entuzjastą GitOps, który poruszałem dość szczegółowo w ostatnich odcinkach podcastu.\nJak masz wszystko w kodzie, to umożliwiasz agentom AI usprawnianie Twojej platformy. To dlatego, że podobnie jak w przypadku książek, LLMy bazują na tekście i potrafią go świetnie zrozumieć. A Ty wtedy skupiasz się na budowaniu mentalnych modeli (ktoś musi mieć wiedzę, aby wydawać polecenia i weryfikować halucynacje) zamiast wykonywać żmudne zadania.\nA jak to się ma do mojego dziwactwa pisania dokumentacji? Pozwól, że wytłumaczę posługując się przykładem z jednego z moich projektów.\nDuży projekt, jeszcze większe wyzwania Wszystko działa pięknie podczas demo z tutoriali oraz też w małych startupach. Co innego, jak projekty są naprawdę w dużej skali.\nPewnie też to znasz. Duże środowiska to dużo rozwiązań, dużo klastrów, oddzielne zespoły rozproszone geograficznie, Jira, Confluence i mnóstwo procedur/approvali. W takim środowisku również uczestniczę, gdzie jest sporo rzeczy do zrobienia, bo też skala jest olbrzymia.\nOd strony technicznej jest mniej więcej jasne, jak dowieźć projekt. Problemem jest brak informacji o szczegółach. Nie mogę ich tu oczywiście podać, ale z reguły kończy się to poszukiwaniem osób z wiedzą o danym obszarze. Przypomina mi to opisywany dawno temu przykład wiedzy plemiennej i jak widać temat jest wciąż aktualny.\nJa mam lekką awersję do spotkań, jeśli czuję, że tracę czas. One jednocześnie wysysają energię i przeszkadzają w dowożeniu wartości do projektu. Niestety, większość spotkań jest niepotrzebna (coś w stylu \u0026ldquo;This meeting should be an email\u0026rdquo;), a zamiast tego wystarczyłoby mieć dobrą dokumentację.\nNie zrozum mnie źle - dokumentacja jakaś jest. Jeśli jest napisana tak sobie, to i tak jest super, bo dzięki czatom z agentami AI da się jej całkiem nieźle użyć. Gorzej, jak jej nie ma lub nie odzwierciedla rzeczywistości (jest nieaktualna lub błędna).\nLepsze zastosowanie AI Piękne są te posty o agentach AI i sam pracuję nad projektem, gdzie będą one współtworzyć platformę na podstawie GitOps. Ale co jeśli już teraz możemy rozwiązać bieżące problemy o wiele łatwiej dzięki AI?\nNie każdy lubi i chce pisać dokumentację. Ok, to niech napisze ją AI. Dajmy mu kilka punktów lub jeszcze lepiej - dostęp do rozwiązania i niech go sprawnie opisze. Albo nawet możemy ominąć krok dokumentacji i od razu dać dostęp do źródeł wiedzy, które pomogą odnaleźć istotne dla nas informacje.\nTo ostatnie obarczone jest pewnym ryzykiem (bezpieczeństwo) i dlatego utworzenie snapshota informacji w postaci dokumentacji jest wystarczająco dobre.\nAle jest kolejne wyzwanie. Dokumentacja potrafi być porozrzucana po różnych stronach w różnych hierarchiach. To nie problem, jeśli nie musimy jej czytać bezpośrednio, tylko czatować z AI. W końcu chodzi nam o zrozumienie lub znalezienie odpowiedzi na nurtujące nas pytanie.\nBez zbędnych spotkań, asynchronicznie, sprawnie i z większą satysfakcją. To zmienia naprawdę wiele i jest nisko wiszącym owocem.\nAby użyć AI jako force-multiplier do budowania mentalnych modeli, potrzebujemy pracować nad zrozumieniem systemu, z którym pracujemy. I do tego AI nadaje się wyśmienicie.\nPiszmy zatem dokumentację. Lub lepiej - niech AI pisze ją za nas.\n🔥 KCD Warsaw 2025 już za tydzień Przypominam, że już za tydzień jest konferencja, którą współorganizuję i na której będę ja oraz inni ludzie z branży. Warto się spotkać!\nTo pierwsza taka konferencja w Polsce. Jest to impreza non-profit pod oficjalnym patronatem CNCF i odbędzie się 9 października 2025 w Warszawie.\nMamy fajne miejsce, interesujące prezentacje (wybór był ciężki) i ogromne zainteresowanie ludzi. Ja wraz z innymi wolontariuszami wkładamy mnóstwo wysiłku, aby było to wyjątkowe wydarzenie. Jeszcze sporo pracy przed nami, ale już teraz możesz się zarejestrować ze specjalną 20% zniżką.\n🎟️ Użyj specjalnego kodu przy rejestracji:\nCLOUDOWSKI20\nLiczba biletów jest ograniczona przez samo miejsce i fakt, że impreza nie ma celu komercyjnego - liczy się wartość, jaką przyniesie naszej społeczności. Samo miejsce jest bardzo fajne, bo w samym centrum Warszawy, w nowoczesnym Varso Tower, tuż obok Dworca Centralnego.\nA dlaczego warto wpaść?\nOto 3️⃣ najważniejsze powody według mnie:\nSpotkanie innych entuzjastów - jako introwertyk, ale jednocześnie pasjonat bardzo doceniam spotkania z innymi ekspertami i ciekawe dyskusje Prezentacje na żywo - można oglądać na YouTube, ale na żywo jest zdecydowanie lepiej - to jak taki koncert tylko dla geeków Fajny klimat - sporo się napracowaliśmy nad budową fajnego klimatu imprezy dla profesjonalistów z branży bez zadęcia i ciągłej sprzedaży 👉 Zarejestruj się już teraz na stronie wydarzenia i do zobaczenia już za tydzień!\n","tags":["podcast","devops","platformengineering","gitops","ai"],"title":"Newsletter #137 - Dlatego jestem dziwny"},{"categories":null,"date":"October 2, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/why-documentation-matters-even-more-now/","section":"blog","summary":"Okay, I\u0026rsquo;ll admit it: I\u0026rsquo;m a bit weird. My weirdness? I love writing documentation. I know, not exactly rock and roll. But there\u0026rsquo;s something about putting things down in writing that helps me understand them better. It\u0026rsquo;s like my brain needs to see it on paper (or a screen) to really click.\nTurns out, this isn\u0026rsquo;t just a personal quirk – it\u0026rsquo;s becoming a superpower in the age of AI.\nYears ago, I took a Gallup StrengthsFinder test, and one of my top strength was \u0026ldquo;Input.\u0026rdquo; Basically, I\u0026rsquo;m wired to collect and organize information. Which, hey, explains the documentation thing!\nWriting Isn\u0026rsquo;t Going Anywhere Even with all the cool new tech, writing is still a big deal. We still have books, articles, and all kinds of written stuff. I\u0026rsquo;m the kind of person who likes the nitty-gritty, the real details. That\u0026rsquo;s why I subscribe to O\u0026rsquo;Reilly – tons of in-depth knowledge packed into one place. I use it to feed my brain with stuff to work on.\nIf you\u0026rsquo;re reading this, you probably value writing too. That\u0026rsquo;s awesome! In a world of short attention spans, taking the time to read is a win.\nBut here\u0026rsquo;s the big reason why writing matters now more than ever: AI. Specifically, LLMs (Large Language Models). Think of it this way: AI doesn\u0026rsquo;t magically create awesome stuff. It learns from massive amounts of text. So, someone needs to write that text!\nThis is a big deal. Even big enough that AI companies are having to pay up to authors whose work was used to train their models. Knowledge in books is crazy valuable.\nAnd it\u0026rsquo;s not just books. Code is text too! That\u0026rsquo;s why I\u0026rsquo;m so into GitOps. I won\u0026rsquo;t get too technical, but basically, when you manage your infrastructure with code, you can let AI agents help make things better. LLMs are good at understanding text, so they can understand code. This means we can focus on the big picture – building the right mental models – instead of getting bogged down in boring tasks. But how does all this connect to my documentation obsession? Here\u0026rsquo;s a story.\nBig Projects, Big Problems Everything\u0026rsquo;s great in a demo, right? And startups can be pretty smooth too. But when you\u0026rsquo;re working on a huge project, it\u0026rsquo;s a different ballgame. Lots of moving parts, lots of people, lots of… well, you get the idea.\nI\u0026rsquo;m working on one of those projects now. And while we generally know how to get the job done, the real problem is a lack of information. Finding the specific detail you need? It can feel impossible. It\u0026rsquo;s like this \u0026ldquo;tribal knowledge\u0026rdquo; thing – where only a few people know how something really works.\nI hate meetings that waste time. They suck energy and stop me from getting stuff done. And honestly, most meetings could be emails (or better yet, documented!). Now, there\u0026rsquo;s some documentation. But even okay documentation is better than nothing, because AI can help you use it. The worst case? No docs, or docs that are wrong.\nAI to the Rescue (Again!) It\u0026rsquo;s cool to think about AI agents automating stuff (and I\u0026rsquo;m working on a project like that myself!). But we can use AI to fix problems today.\nNot everyone loves writing documentation (I get it, I\u0026rsquo;m the weird one!). So, let AI do it! Give it some pointers, or better yet, let it look at the system itself. It can write up a description. You could even skip the whole \u0026ldquo;document\u0026rdquo; thing and let AI answer questions directly.\nThat last one is a bit risky from a security standpoint, so creating a snapshot of info as documentation is good enough. But even with docs, things can get scattered. That\u0026rsquo;s where AI comes in again. Instead of reading through pages of stuff, you can chat with AI. Ask it a question, get a clear answer. No meetings, quick answers, less frustration. It\u0026rsquo;s a win-win-win. And it\u0026rsquo;s a pretty easy win – a low-hanging fruit.\nTo really use AI to its fullest, to build those mental models, we need to understand the systems we\u0026rsquo;re working with. And AI is the perfect tool to help us do that. So, let\u0026rsquo;s write stuff down. Or better yet, let AI write stuff down for us.\n","tags":["devops","platformengineering","architecture","ai"],"title":"Why Documentation Matters Even More Now"},{"categories":null,"date":"September 4, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/136/","section":"newsletter-archive","summary":"Długo nie pisałem, gdyż w tym czasie zajmowałem się głównie zdrowiem, ciekawymi projektami oraz konferencją KCD Warsaw 2025.\nMam dla ciebie kod zniżkowy i liczę, że wpadniesz na to wyjątkowe wydarzenie.\nNajpierw zdrowie, potem praca i AI Każdy ma swoje własne priorytety. Moim priorytetem jest zdrowie i to jest jeden z powodów, dla których nie byłem ostatnio zbyt aktywny. Korzystam z uroków Warszawy, która ma specjalistów z różnych dziedzin medycyny. Naprawdę jestem wdzięczny, że mogę skorzystać z ich pomocy.\nNie próżnuję jednak, bo jakoś tak mam, że nie mogę siedzieć spokojnie. Po lecie w mieście wybyłem do mojej ulubionej Walencji, gdzie cieszę się z uroków mniejszej liczby turystów, doskonałej plaży i jedzenia.\nObecnie pracuję nad kilkoma ciekawymi projektami. Jeden z nich szczególnie mnie zaciekawił. Chodzi o praktyczne wykorzystanie agentów AI do zarządzania platformą.\nOpisałem to na moich social media jakiś czas temu i w tym krótkim artykule. Pewnie nagram o tym jakieś wideo, podcast oraz będę jeszcze pisał, bo mnie to naprawdę mocno wciągnęło.\nAle sporo czasu też poświęcam organizacji konferencji KCD Warsaw 2025. I liczę, że wpadniesz na nią spotkać mnie i innych entuzjastów.\nMoże namówi cię do tego specjalna 20% zniżka 🙂\nKonferencja KCD Warsaw 2025 To pierwsza taka konferencja w Polsce. Jest to impreza non-profit pod oficjalnym patronatem CNCF i odbędzie się 9 października 2025 w Warszawie.\nMamy fajne miejsce, interesujące prezentacje (wybór był ciężki) i ogromne zainteresowanie ludzi. Ja wraz z innymi wolontariuszami wkładamy mnóstwo wysiłku, aby było to wyjątkowe wydarzenie. Jeszcze sporo pracy przed nami, ale już teraz możesz się zarejestrować ze specjalną 20% zniżką.\n🎟️ Użyj specjalnego kodu przy rejestracji:\nCLOUDOWSKI20\nLiczba biletów jest ograniczona przez samo miejsce i fakt, że impreza nie ma celu komercyjnego - liczy się wartość, jaką przyniesie naszej społeczności. Samo miejsce jest bardzo fajne, bo w samym centrum Warszawy, w nowoczesnym Varso Tower, tuż obok Dworca Centralnego.\nA dlaczego warto wpaść?\nOto 3️⃣ najważniejszych powodów według mnie:\nSpotkanie innych entuzjastów - jako introwertyk, ale jednocześnie pasjonat bardzo doceniam spotkania z innymi ekspertami i ciekawe dyskusje Prezentacje na żywo - można oglądać na YouTube, ale na żywo jest zdecydowanie lepiej - to jak taki koncert tylko dla geeków Fajny klimat - sporo się napracowaliśmy nad budową fajnego klimatu imprezy dla profesjonalistów z branży bez zadęcia i ciągłej sprzedaży 👉 Zarejestruj się już teraz na stronie wydarzenia i do zobaczenia w październiku!\nOdcinki podcastu o GitOps W międzyczasie nagrałem dwa odcinki i oba o GitOps. Coś w tym musi być. A do tego na najbliższej konferencji DevOpsDays Warsaw opowiem o tym więcej na żywo.\n32 - Największe wyzwania GitOps Czy warto wdrożyć podejście GitOps? Oczywiście! Czy to łatwe? To zależy 😅\nTa część jest rozwinięciem poprzedniego odcinka i tym razem omawiam w niej największe wyzwania z jakimi przychodzi się mierzyć tym, którzy chcą zarządzać wszystkim z kodu.\nA czego konkretnie się z niej dowiesz? Oto najważniejsze tematy, które tu poruszam:\n🔹 Czym jest Hub-and-Spoke dla GitOps?\n🔹 Czy lepiej zarządzać zmianami centralnie czy w sposób rozproszony?\n🔹 Jak przechowywać bezpiecznie dane poufne w repozytorium z kodem?\n🔹 Kiedy możesz zrezygnować z utrzymywania obiektów Secret?\n🔹 Jak zarządzać zmianami przez referencje?\n🔹 W jaki sposób dostarczać informacje o zaaplikowanych zmianach?\n🔹 Jak porządnie zarządzać aplikacjami stanowymi w całości z kodu?\n🎧 Sprawdź i posłuchaj na stronie odcinka\n🎥 Obejrzyj na YouTube\n33 - Jak wdrażać aplikacje bez potoków CI/CD Kontynuuję temat GitOps i tym razem przedstawiam jego trudniejszą część. Łatwo bowiem definiować niezbyt często zmieniające się elementy samej platformy, ale co innego jak potrzebne jest zintegrowanie tego z częstymi wdrożeniami aplikacji.\nNa szczęście dzięki deklaratywnemu podejściu, jakie daje nam między innymi Kubernetes, łatwo jest rozdzielić tradycyjny potok CI/CD na części CI i CD. Ta pierwsza nadal obsługiwana jest przez potok, ale druga już przez silnik GitOps.\nPosłuchaj tego odcinka, gdzie opowiadam o szczegółach oraz problemach, jakie rozwiązuje takie podejście:\n🔹 Do czego nam jest potrzebny CI/CD?\n🔹 Jakie problemy są z połączeniem CI oraz CD?\n🔹 Jak wdrażane są aplikacje na PaaS, VM i Kubernetes?\n🔹 Na czym polega rozdzielenie CI od CD?\n🔹 Jakie korzyści daje podejście GitOps do wdrożeń aplikacji?\n🎧 Sprawdź i posłuchaj na stronie odcinka\n🎥 Obejrzyj na YouTube\n","tags":["podcast","devops","platformengineering","gitops"],"title":"Newsletter #136 - GitOps + CI/CD i zaproszenie na konferencję"},{"categories":null,"date":"August 31, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/33/","section":"podcast","summary":"Kontynuuję temat GitOps i tym razem przedstawiam jego trudniejszą część.\nŁatwo bowiem definiować niezbyt często zmieniające się elementy samej platformy, ale co innego jak potrzebne jest zintegrowanie tego z częstymi wdrożeniami aplikacji.\nNa szczęście dzięki deklaratywnemu podejściu jakie daje nam między innymi Kubernetes, łatwo jest rozdzielić tradycyjny potok CI/CD na części CI i CD. Ta pierwsza nadal obsługiwana jest przez potok, ale druga już przez silnik GitOps.\nPosłuchaj tego odcinka, gdzie opowiadam o szczegółach oraz problemach jakie rozwiązuje całościowe takie podejście:\n🔹 Do czego nam jest potrzebny CI/CD?\n🔹 Jakie problemy są z połączeniem CI oraz CD?\n🔹 Jak wdrażane są aplikacje na PaaS, VM i Kubernetes?\n🔹 Na czym polega rozdzielenie CI od CD?\n🔹 Jakie korzyści daje podejście GitOps do wdrożeń aplikacji?\nDiagram rozwiązania Oto obiecany diagram opisujący rozwiązanie z odcinka:\nNa stronie solutions/kubernetes-deployment-factory/ przedstawiam więcej szczegółów rozwiązania oparteygo w całości z kodu.\nKonferencja KCD Warsaw 2025 Jak współorganizator konferencji KCD Warsaw 2025 serdecznie Cię na nią zapraszam!\nOdbędzie się ona 9 października 2025 w centrum Warszawy w Varso Tower tuż obok Dworca Centralnego (świetny dojazd!).\nTo jest impreza non-profit organizowana przez wolontariuszy i wszystkie przychody przeznaczamy na pokrycie jej kosztów.\n🔥 Użyj kodu CLOUDOWSKI20 do rejestracji, aby kupić bilet o 20% taniej.\nDo zobaczenia na miejscu!\n","tags":["devops","gitops","cicd","jenkins","gitlab","platformengineering"],"title":"33 - Jak wdrażać aplikacje bez potoków CI/CD"},{"categories":null,"date":"August 21, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/ai-managed-platform-for-apps/","section":"blog","summary":"I’m working on a fascinating project that leverages AI to tackle Platform Engineering challenges.\nIt’s time to harness AI to make platform engineering more efficient. With more applications coming to our platforms, we must prepare for this influx using LLMs and AI Agents.\nWhy I\u0026rsquo;m building it I’ve always been a passionate advocate and practitioner of the Everything-as-Code approach (formerly Infrastructure-as-Code). I ❤️ creating platforms managed entirely from code (a.k.a. GitOps) and have explored various tools to achieve this goal.\nFirst, it was Kickstart, which I used to boot up machines via PXE and install Linux in an automated and unified way.\nThen came the cloud, with CloudFormation, Terraform, Ansible, and Packer, enabling autoscaling and immutable infrastructure.\nFinally, Docker appeared, followed soon by Kubernetes, revolutionizing infrastructure management and taking platform management to a new level!\nBut here’s the thing: we don’t need Terraform, OpenTofu, Kubernetes, Docker, Argo CD, Jenkins, or other fancy tools. What we truly need is an EASY way to run apps using Kubernetes as a foundation.\nI know how it should work, which components to use, and it looks very promising! I\u0026rsquo;ve started building it to address common challenges in the Platform Engineering and DevOps fields.\nOver the past 20 years, I’ve seen many companies struggle to provide a reliable, secure, and efficient platform for running their apps.\nMore expertise needed One of the main reasons for these struggles is the shortage of DevOps experts with broad knowledge of complex infrastructure.\nIn many cases, AI outperforms humans in implementing solutions with code. And it continues to improve with more sophisticated LLMs under active development.\nAfter months of learning and experimentation, I finally discovered how AI can address many challenges of maintaining platforms, particularly those based on Kubernetes.\nAI works best with code I’ve learned how LLMs work, and the conclusion is simple: they need text to understand context, connections, and intents.\nThe platform can be managed entirely from code, building and delivering apps with the help of AI.\nTo fully utilize AI for platform management, you must keep everything as code. This opens the door to significant opportunities for saving time, simplifying deployments, and enhancing security.\nAI Agents managing platform via MCP AI agents can use the code to improve and develop the platform.\nMCP is used to enhance the platform by keeping all changes in code.\nKubernetes enables you to run apps in multiple regions, clouds, and providers at a low cost.\nCode-based management enhanced with AI makes it a future-proof solution.\nWhat next Is it ready? NOT YET.\nDo I know how to build it? YES.\nWill it transform the way organizations manage their platforms? DEFINITELY!\nWould you like to find out more? If so, please contact me directly. Let’s talk!\n","tags":["devops","platformengineering","architecture","ai","cloud","onprem","kubernetes","mcp"],"title":"I'm building an AI-managed platform for apps"},{"categories":null,"date":"July 23, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/its-not-about-tools/","section":"blog","summary":"Have you ever had a problem and spent a lot of time finding the proper tool to solve it?\nWell, I have — many times. Here are some of my recent realizations:\n🚫 Another display won’t make me more productive — I need to learn to be systematic first.\n🚫 A better camera, new lights, or a new microphone for my studio won’t make my content more engaging — it’s still my job to come up with interesting ideas.\n🚫 New processes won’t make my fear of rejection and direct communication go away — I need to learn to listen more, overcome my doubts, and face challenging situations.\nTools can be very useful, and by using them, we can achieve great things. However, I’ve often seen people in work environments focus too much on finding THE RIGHT tool to fix their problems.\n\u0026ldquo;Let’s solve it by implementing project X,\u0026rdquo; or \u0026ldquo;Let’s buy this product\u0026rdquo; or worse:\n\u0026ldquo;Let’s BUILD a tool for that.\u0026rdquo; 🤦\n⛔️ NO, a more sophisticated ticket system doesn’t solve communication challenges in your company — it often enables nagging and escalation but won’t fix the underlying problem.\n⛔️ NO, Kubernetes won’t solve the software architectural mess and chaos — it might postpone it for a while, but it will eventually blow up.\n⛔️ NO, using Cloud doesn’t make you Cloud Native — you still need to work on well-designed architecture, scalability, observability, and collaboration with teams to bring real benefits.\nThese tools may be necessary, but not yet.\n⚠️ Be cautious of the false promises made by products, salespeople, and influencers, as their messages are often designed to entice you to buy things.\nYou probably don’t need these things, and you may never need them, as they may be substitutes for the hard work that’s truly required.\n","tags":["devops","platformengineering","architecture"],"title":"No, it's not about tools"},{"categories":null,"date":"July 13, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/32/","section":"podcast","summary":"Czy warto wdrożyć podejście GitOps? Oczywiście! Czy to łatwe? To zależy 😅\nTa część jest rozwinięciem poprzedniego odcinka i tym razem omawiam w niej największe wyzwania z jakimi przychodzi się mierzyć tym, którzy chcą zarządzać wszystkim z kodu.\nA czego konkretnie się z niej dowiesz? Oto najważniejsze tematy, które tu poruszam:\n🔹 Czym jest Hub and Spoke da GitOps?\n🔹 Czy lepiej zarządzać zmianami centralnie czy w sposób rozproszony?\n🔹 Jak przechowywać bezpiecznie dane poufne w repozytorium z kodem?\n🔹 Kiedy możesz zrezygnować z utrzymywania obiektów Secret?\n🔹 Jak zarządzać zmianami przez referencje?\n🔹 W jaki sposób dostarczać informacje o zaaplikowanych zmianach?\n🔹 Jak porządnie zarządzać aplkikacjami stanowymi w całości z kodu?\nLinki 🔗 Opis mojego rozwiązania z GitOps - https://cloudowski.com/solutions/kubernetes-deployment-factory/\n🔗 Projekt SOPS - https://getsops.io/\n🔗 HashiCorp Vault - https://developer.hashicorp.com/vault\n🔗 External Secrets - https://external-secrets.io/latest/\n🔗 Secrets Store CSI Driver - https://secrets-store-csi-driver.sigs.k8s.io/\n","tags":["devops","gitops","platformengineering"],"title":"32 - Największe wyzwania GitOps"},{"categories":null,"date":"July 8, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/135/","section":"newsletter-archive","summary":"Ostatnio miałem przyjemność opowiadać o GitOps na dwóch konferencjach i muszę przyznać, że temat wzbudził spore zainteresowanie. To pokazuje, że coraz więcej osób dostrzega potencjał GitOps w budowaniu platform i automatyzacji wdrożeń.\nJa nawet nie mogę sobie bez tego podejścia wyobrazić nowych projektów i dziś chcę Ci opowiedzieć, dlaczego GitOps jest tak ważny, jakie problemy rozwiązuje i jak możesz go zacząć implementować w swojej organizacji.\nCzy te sytuacje są Ci znane? Czas na GitOps! Czy znasz to uczucie kiedy:\nJesteś znowu sfrustrowany powtarzającymi się problemami z wdrożeniami wynikającymi z brakiem spójności środowisk? Zdarzają się \u0026ldquo;quickfixy na boku\u0026rdquo;, które niszczą porządek? Ręce drżące przed każdą aktualizacją z obawy przed katastrofą? Wkurza Cię brak możliwości szybkiego rollbacku i pewności, że wszystko wróci do normy? Irytuje Cię wiedza tajemna o infrastrukturze i wdrożeniach, dostępna tylko dla \u0026ldquo;szamanów\u0026rdquo;? Jeśli odpowiedziałeś \u0026ldquo;tak\u0026rdquo; na którekolwiek z tych pytań, to GitOps może być odpowiedzią na Twoje problemy.\nCzym Jest GitOps? GitOps to, najprościej mówiąc, operacje oparte o Git. Kiedyś mówiliśmy o Infrastructure as Code, a dziś, dzięki systemom deklaratywnym jak Kubernetes i popularności narzędzi typu Terraform, mówimy o Everything as Code.\nGitOps to ewolucja tego podejścia. To deklaratywne zarządzanie systemami (infrastrukturą, aplikacjami, konfiguracją) za pomocą kodu przechowywanego w repozytorium Git. Git staje się jedynym źródłem prawdy o Twoim systemie. Wszelkie zmiany są wprowadzane przez commit, pull requesty, a następnie automatycznie synchronizowane z systemem.\nDlaczego GitOps jest teraz jeszcze ważniejszy? Świat IT staje się coraz bardziej złożony, a GitOps pomaga zapanować nad tym chaosem. Dlaczego teraz jest tak istotny?\nŁatwa skalowalność: GitOps ułatwia skalowanie na wiele środowisk, klastrów i regionów. Zwiększone bezpieczeństwo: Automatyzacja na poziomie Git, transparentność, łatwy audyt i szybsze naprawianie luk bezpieczeństwa. Lepsza współpraca między zespołami: Git to jedno źródło prawdy i miejsce współpracy nad kodem platformy, bezpieczeństwem i procesami wdrażania opisanymi kodem. Szybsze wprowadzanie zmian: Od pomysłu/poprawki do Gita i później prostsza droga do środowiska. Proste również wycofywanie zmian w razie problemów. Jak Zacząć Implementować GitOps? Masz kilka opcji:\nDla Kubernetes: Argo CD: Najczęściej wybierany silnik GitOps dla Kubernetes. Flux CD: Alternatywa dla Argo CD, również skupiona na Kubernetesie. Dla cloud: Crossplane: Silnik GitOps do zarządzania zasobami w wielu chmurach. Terraform/OpenTofu: Alternatywne podejście do zarządzania chmurą za pomocą kodu. Pulumi: Kolejne narzędzie do Infrastructure as Code, ale też do Everything as Code. Dla pozostałych systemów możesz stworzyć własne rozwiązanie, które będzie implementować zmiany opisane kodem. To trudniejsze, ale wykonalne.\nWięcej o GitOps w nowym odcinku podcastu \u0026ldquo;Rozchmurzony\u0026rdquo; Zapraszam do wysłuchania 31 odcinka podcastu - \u0026ldquo;Wszystko w kodzie, czyli dlaczego potrzebujemy GitOps\u0026rdquo;.\nPosłuchaj/obejrzyj, aby dowiedzieć się więcej szczegółów o tematach dzisiejszego newslettera oraz:\nCzym jest Single Source of Truth Dlaczego GitOps stał się teraz tak ważny Jak to podejście podnosi znacząco bezpieczeństwo W jaki sposób GitOps wspiera DevOps Czy GitOps może zmniejszać ryzyko wprowadzania zmian Link do strony odcinka: https://cloudowski.com/podcast/31/\nNagranie na YouTube: https://youtu.be/kMsqASDh3Sg\n","tags":["podcast","devops","platformengineering","gitops"],"title":"Newsletter #135 - Czas na GitOps"},{"categories":null,"date":"June 29, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/31/","section":"podcast","summary":"Dużo w ostatnich latach mówiłem o podejściu do zarządzania z kodu. Najpierw był to Infrastructure-as-Code (IaC) z Immutable Infrastructure, później o deklaratywnych systemach jak Kubernetes i w końcu o Everything-as-Code.\nW tym odcinku poruszam temat GitOps, który jest niejako następcą pozostałych i staje się coraz bardziej popularny.\nTo pierwszy z kilku części cyklu o GitOps, a w tym odcinku opowiadam między innymi o:\nCzym jest GitOps Czym jest Single Source of Truth Jakie są najpopularniejsze narzędzia do GitOps Dlaczego GitOps stał się teraz tak ważny Jak to podejście podnosi znacząco bezpieczeństwo W jaki sposób GitOps wspiera DevOps Czy GitOps może zmniejszać ryzyko wprowadzania zmian Linki Projekt Argo CD - https://argoproj.github.io/cd/ Projekt Flux - https://fluxcd.io/ Projekt Crossplane - https://www.crossplane.io/ Projekt Pulumi - https://www.pulumi.com/ ","tags":["devops","gitops"],"title":"31 - Wszystko w kodzie, czyli dlaczego potrzebujemy GitOps"},{"categories":null,"date":"June 17, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/134/","section":"newsletter-archive","summary":"Ostatnio coraz częściej słychać o pozycjach Platform Engineer i Platform Architect obok DevOps Engineer.\nCzy to znak, że czas na zmianę? Przekwalifikowanie się? Czy DevOps odchodzi do lamusa? Spokojnie, bez paniki! Fakt, to pewna zmiana, ale nie tak radykalna.\nCzy koncept DevOps odchodzi do lamusa? Nie, DevOps nie umiera. To raczej ewolucja, a nie rewolucja. Większość z tego, co teraz nazywamy Platform Engineeringiem, to tak naprawdę dobrze znane nam praktyki DevOps, tylko z większym naciskiem na konkrety.\nPrzez lata dużo mówiliśmy o kulturze DevOps i chyba wszyscy już wiemy, że jest ona ważna. Niektórzy są już nawet tym zmęczeni i wolą działać niż mówić (wraz z autorem).\nKultura sama w sobie nie wystarczy. Kultura DevOps ma na celu tworzenie środowiska sprzyjającego usprawnianiu i przyspieszaniu wdrażania innowacji. A tym, co tworzymy, są platformy dla wszelkiego rodzaju aplikacji.\nPlatform Engineering: Narzędzia i praktyki, które już znasz Platform Engineering to zbiór narzędzi i praktyk, które znamy i wykorzystujemy od dawna. Nie ma tu żadnej magii.\nNarzędzia: Kontenery, Kubernetes, chmura, Terraform/OpenTofu, maszyny wirtualne, sieci, rozproszony storage itd. To wszystko już dobrze znamy. Praktyki: Chaos Engineering, Design for Failure, Observability, GitOps, Everything-as-Code i wiele innych. To filary nowoczesnego DevOps. Platform Engineering: Zmiana perspektywy, a nie rewolucja Różnica polega na zmianie perspektywy. Nie skupiamy się już tylko na dostarczaniu oprogramowania, ale na dostarczaniu platformy z usługami, które umożliwiają budowanie, testowanie, wdrażanie i bezproblemowe działanie wszelkiego rodzaju aplikacji.\nA tych będzie coraz więcej, bo dzięki AI łatwiej jest pisać nowe, zmieniać stare, migrować z monolitów do mikroserwisów i eksperymentować.\nPlatform Engineering to:\nDostarczanie Platformy: Budowanie fundamentów, na których działają aplikacje. Usługi dla Deweloperów: Umożliwienie deweloperom samodzielnego budowania, testowania i wdrażania oprogramowania. Bezproblemowe Działanie: Zapewnienie stabilności, skalowalności i bezpieczeństwa aplikacji. Platforma ma być wewnętrznym produktem, który jest stabilny, bezpieczny, niezawodny oraz zoptymalizowany kosztowo.\nDevOps nie odchodzi, on ewoluuje. Platform Engineering to naturalny krok naprzód, który skupia się na konkretnych narzędziach i praktykach, a nie tylko na kulturze.\nTo skupienie się na budowaniu platform, które umożliwiają innowacje i dostarczanie wartości.\nCzy to oznacza, że musisz się przekwalifikować? Niekoniecznie. Jeśli znasz DevOps, to znasz już większość elementów Platform Engineeringu. Musisz tylko przestawić myślenie i skupić się na budowaniu platform, a nie tylko na dostarczaniu aplikacji.\nPosłuchaj i obejrzyj więcej w podcaście \u0026ldquo;Rozchmurzony\u0026rdquo;. Zapraszam do wysłuchania tego odcinka, z którego dowiesz się między innymi:\nCo jest najbardziej cenioną cechą DevOps Gdzie sprawdzić liczby i fakty pokazujące realne korzyści wynikające z DevOps Dlaczego być może przedobrzyliśmy z tą \u0026ldquo;kulturą DevOps\u0026rdquo; Czym jest i na czym skupia się Platform Engineering Czy to definitywny koniec DevOps Link do strony odcinka: https://cloudowski.com/podcast/30/\nNagranie na YouTube: https://youtu.be/iGpxCUbfx4U\nSpotkaj mnie na tych wydarzeniach Cloud Native Warsaw - June 2025\n🗓️ Warszawa, 11 czerwca 18:00\nIT Unplugged\n🗓️ Lublin, 10 czerwca\nTemat: [PL] Synergia GitOps i potoków CI/CD\nDevoxx Poland\n🗓️ Kraków, 11-13 czerwca Temat: [EN] Synergy of GitOps and CI/CD pipelines\n","tags":["podcast","devops","platformengineering"],"title":"Newsletter #134 - Czy to koniec DevOps?"},{"categories":null,"date":"June 16, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/public-speaking-is-fun-but-requires-practices/","section":"blog","summary":" I started doing public speaking over 10 years ago. For an introvert like me, it wasn\u0026rsquo;t easy at first, but over time I\u0026rsquo;ve overcome my doubts and fears, and silenced the critical voice in my head.\nI now really enjoy providing talks and speaking about topics that interest me.\nOver the past two weeks, I have attended three conferences:\n1️⃣ Confidence 2025 in Cracow (Hacking Kubernetes)\n2️⃣ IT Unplugged in Lublin (Synergy of GitOps and CI/CD)\n3️⃣ Devoxx Poland in Cracow (Synergy of GitOps and CI/CD)\nIf I can do it (learn it) so can you! 💪\nPublic speaking is something that doesn\u0026rsquo;t require AI and it\u0026rsquo;s mostly about practice, regardless of whether you\u0026rsquo;re an introvert or not.\nIt really boosts confidence and brings joy, as well as hopefully providing value for the listeners.\nSo why not try?\n","tags":["conferences"],"title":"Public speaking is fun but requires practice"},{"categories":null,"date":"June 11, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/is-devops-being-replaced-with-platform-engineering/","section":"blog","summary":"\nPlatform Engineer roles popping up everywhere. Is DevOps really dead this time? Is this just DevOps 2.0 in disguise?\nLet\u0026rsquo;s be clear: This isn\u0026rsquo;t a brand new concept, but more about a focused shift – and the name change helps leverage that \u0026ldquo;shiny new thing\u0026rdquo; effect.\nSo, what\u0026rsquo;s really going on? It\u0026rsquo;s less about replacing DevOps and more about focusing on the “Platform” and good Engineering practices – tangible outcomes, not just culture.\nBecause culture + action = true progress! We\u0026rsquo;re evolving, not abandoning the core DevOps principles.\nFor years, we\u0026rsquo;ve talked about DevOps culture. Now it\u0026rsquo;s time to focus on providing value! And the right approach is to deliver a well-engineered platform.\nPlatform Engineering is about:\nFocusing on the Platform Itself: Treating the underlying infrastructure as a product. Engineering Practices: Applying core software engineering principles to infrastructure and operations. Think design, testing, and maintainability first. Empowering Developers: Building internal platforms that enable developers to self-serve and move faster. And AI changes the game. It changes it a lot. AI makes creating new apps easier than ever. This means a massive increase in the number of applications. A well-designed, scalable platform is now essential to manage this explosion of new apps.\nSo, is this the future we really need? Does this name change help?\nLet me know your thoughts on this #PlatformEngineering evolution in the comments! 👇\n#DevOps #PlatformEngineering #Kubernetes #CloudNative #InternalDeveloperPlatform #EngineeringPractices #AI #ArtificialIntelligence #FutureOfIT\n","tags":["devops","platformengineering","ai"],"title":"Is DevOps being replaced with Platform Engineering?"},{"categories":null,"date":"June 9, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/30/","section":"podcast","summary":"Czy DevOps ustępuje podejściu Platform Engineering? Czy to kolejny buzzword, a może realna zmiana warty?\nPo ponad 15 latach od kiedy świat usłyszał o DevOps coraz częściej słyszy się o Platform Engineering.\nMoże to nie przypadek i warto wiedzieć co stoi za tym zjawiskiem.\nZapraszam do wysłuchania tego odcinka, z którego dowiesz się między innymi:\nCo jest najbardziej cenioną cechą DevOps Gdzie sprawdzić liczby i fakty pokazujące realne korzyści wynikające z DevOps Dlaczego być może przedobrzyliśmy z tą \u0026ldquo;kulturą DevOps\u0026rdquo; Czym jest i na czym skupia się Platform Engineering Czy to definitywny koniec DevOps Linki Strona DORA z raportami \u0026ldquo;State of DevOps\u0026rdquo; - https://cloud.google.com/devops/state-of-devops ","tags":["devops","platformengineering","kariera","praca"],"title":"30 - Czy Platform Engineering zastąpił DevOps?"},{"categories":null,"date":"May 30, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/its-just-this-once-gitops-meme/","section":"blog","summary":"\nIf you leave the door open for changes outside of GitOps, there\u0026rsquo;s 100% chance someone will use it, as\nthey are in a hurry they have special circumstances CEO/CTO asked them to do it in person it\u0026rsquo;s just this once only and they will surely make the change in the code later on* *Never happens\n","tags":["meme","automation","gitops"],"title":"It's just this once - I promise!"},{"categories":null,"date":"May 27, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/133/","section":"newsletter-archive","summary":"Zdecydowałem i zadziałałem. Powróciłem do mojego podcastu Rozchmurzony.\nSą już dwa nowe odcinki do przesłuchania (oraz obejrzenia) już serdecznie zapraszam.\nDlaczego wracam Po pierwsze, naszło mnie wiele przemyśleń i obserwacji, którymi po prostu musiałem się podzielić. Lubię proces myślenia, analizowania i dzielenia się zdobytą wiedzą.\nPo drugie, sam jestem wiecznym poszukiwaczem niebanalnych treści, a w dzisiejszym internecie, niestety, często przeważa szum nad treścią. Dlatego chcę dodać swoją cegiełkę i dostarczyć Ci wartościowe informacje, które naprawdę coś wnoszą.\nCo się zmieniło Najważniejsza zmiana to akceptacja. Zaakceptowałem fakt, że Rozchmurzony dotrze do węższej, ale bardziej zaangażowanej grupy odbiorców.\nNie będę gonił za milionami odsłuchań. Skupię się na tych, którzy szukają konkretnych przemyśleń i zaawansowanej wiedzy. Do kogo chcę dotrzeć?\nSeniorzy IT: Inżynierowie z bagażem doświadczeń (kilka, kilkanaście, a nawet kilkadziesiąt lat w branży!). Osoby, które widziały już niejedno i cenią sobie dojrzałe spojrzenie na technologię. Menedżerowie IT: Osoby zarządzające zespołami, projektami, architekturą. Liderzy, którzy potrzebują strategicznych wskazówek i wiedzy o tym, jak budować efektywne organizacje. Pasjonaci DevOps i Platform Engineeringu: Wszyscy, którzy interesują się nowoczesnymi praktykami i technologiami z obszaru DevOps, Platform Engineeringu, Cloud Native i chcą iść do przodu. Oto inne, istotne zmiany jakie czekają mój podcast:\nCzęściej odcinki solo: Będę częściej dzielił się swoimi przemyśleniami bez udziału gości. To będzie bardziej bezpośredni i osobisty kontakt. Goście – oczywiście! Ale wybieram rozmówców, którzy naprawdę mają coś ciekawego do powiedzenia. Więcej zaawansowanych tematów: Skupię się na konkretnych zagadnieniach z DevOps i Platform Engineeringu, bez zbędnego lania wody. Budowanie Platform to Przyszłość: Będziemy rozmawiać o tym, jak tworzyć platformy dla aplikacji, w tym dla AI/ML. To jest kierunek, w którym zmierza branża i chcę, aby Rozchmurzony był również pomocny w tym aspekcie. Co w odcinku 28 - Dlaczego zrezygnowałem z AI To bardzo osobisty odcinek, w którym opowiadam o:\nMojej decyzji o powrocie do podcastu i wszystkim, co się zmieniło w moim podejściu. Mojej rezygnacji z dalszych prac nad kursem \u0026ldquo;AI w minutę\u0026rdquo;. Co się stało z moim entuzjazmem? Dlaczego zmieniłem zdanie? Posłuchaj i dowiedz się! Link do odcinka: https://cloudowski.com/podcast/28/\nCo w odcinku 29 - Pęka bańka IT To odcinek dla tych, którzy czują, że w IT coś się zmienia. Poruszam w nim takie tematy, jak:\nCzym tak naprawdę jest bańka IT i jak ją rozpoznać. Po czym widać, że bańka pęka i jakie są tego przyczyny. Co może zrobić ktoś z mniejszym doświadczeniem w tej sytuacji. Jak powinni się zachować doświadczeni profesjonaliści. Czy warto rozważyć wyjście poza IT i dlaczego. Link do odcinka: https://cloudowski.com/podcast/29/\nSpotkaj mnie na tych wydarzeniach Confidence (🔥 -15% rabatu z kodem \u0026ldquo;TEAM15\u0026rdquo; )\n🗓️ Kraków, 2-3 czerwca Temat: [EN] Hacking and Securing Kubernetes\nCloud Native Warsaw\n🗓️ Warszawa, 11 czerwca 18:00\nSzczegóły wkrótce\n👉 Szukamy speakera/speakerki - jeśli chcesz wystąpić to napisz do mnie bezpośrednio\nDevoxx Poland\n🗓️ Kraków, 11-13 czerwca Temat: [EN] Synergy of GitOps and CI/CD pipelines\nIT Unplugged (🔥 -20% rabatu z kodem \u0026ldquo;CLOUDOWSKI20\u0026rdquo; )\n🗓️ Lublin, 10 czerwca\nTemat: [PL] Synergia GitOps i potoków CI/CD\n","tags":["podcast","praca","ai"],"title":"Newsletter #133 - Wracam z podcastem Rozchmurzony"},{"categories":null,"date":"May 25, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/29/","section":"podcast","summary":"Stało się - pęka bańka świata IT 😱\nMiało już zawsze być tak pięknie, a tu proszę - zmiany i to niekoniecznie w tą stronę jaką sobie byśmy życzyli.\nZapraszam do wysłuchania tego odcinka podcastu \u0026ldquo;Rozchmurzony\u0026rdquo;, aby dowiedzieć się:\nCzym jest bańka IT Po czym widać, że pęka i dlaczego Co może zrobić ktoś z mniejszym doświadczeniem Co może zrobić ktoś już doświadczony Czy warto wyjść poza IT i dlaczego Linki Projekty do samodzielnej nauki - https://selfstudy.cloudowski.com/ Kurs \u0026ldquo;Kubernetes po polsku\u0026rdquo; - https://kubernetespopolsku.pl Kurs \u0026ldquo;SkillBooster GitLab CI\u0026rdquo; - https://edu.cloudowski.com/product/skillbooster-gitlab-ci/ Hackathon Civil42 - https://civil42.pl/ ","tags":["devops","ai","platformengineering","praca"],"title":"29 - Pęka nasza piękna bańka IT"},{"categories":null,"date":"May 23, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/we-dont-need-those-devops-guys/","section":"blog","summary":"\n\u0026ldquo;We don\u0026rsquo;t need those DevOps/Platform people anymore!\u0026rdquo; Or maybe we do. 🤔\n","tags":["meme","automation"],"title":"We don't need those devops guys!"},{"categories":null,"date":"May 20, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/when-cloud-agnostic-makes-sense/","section":"blog","summary":"\u0026ldquo;Cloud agnostic\u0026rdquo; sounds amazing – freedom to run anywhere! But is it right for every company? Some truly need it, others just think they do. The reality is a complex game of trade-offs.\nHere\u0026rsquo;s the truth:\nTrying to become cloud-agnostic after starting with one provider is incredibly difficult.\nYou inevitably start using vendor-specific services, creating lock-in. So it\u0026rsquo;s much better to start with cloud agnostic approach. Cloud provider services are easy and that’s their big advantage, but use them wisely! Integrate them thoughtfully, with costs and access controls firmly in place. Otherwise, they will take control over your environment.\nSo, when does cloud-agnostic make sense?\n✅ Genuine Multi-Cloud Needs: A real business case for using multiple clouds.\n✅ Significant Budget: Cloud agnosticism adds complexity and overhead. This is for companies ready to invest in best solutions.\n✅ Clear, Tangible Benefits: Better resilience, lower costs (after accounting for increased operational costs), data sovereignty, or compliance requirements. If there aren\u0026rsquo;t well-defined financial benefits, then you might end up in trouble later, if there will be no budget for keeping agnostic approach.\n💡 My #1 Tip:\nDesign for cloud agnosticism from the start. Test early, and make sure it does work on multiple environments (on-prem + cloud, multi-cloud, etc.). Do it from scratch or don\u0026rsquo;t do it at all!\nHow? Use \u0026ldquo;Everything as Code\u0026rdquo; with tools like Terraform or OpenTofu and of course Kubernetes which makes things a lot easier.\nWhat are your experiences with cloud agnosticism? Is it worth the effort? Share your thoughts in the comments! 👇\n#CloudAgnostic #MultiCloud #Kubernetes #Terraform #OpenTofu #CloudComputing #DevOps #PlatformEngineering #InfrastructureAsCode #CloudStrategy\n","tags":["cloud","cloudagnostic","multicloud"],"title":"When Cloud Agnostic makes sense"},{"categories":null,"date":"May 19, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/132/","section":"newsletter-archive","summary":"Czy powierzenie swoich danych kontenerom i Kubernetesowi to dobry pomysł? Ostatnio w pewnym projekcie ponownie zetknąłem się z wątpliwościami zespołu, bo to pytanie budzi wiele emocji i niepewności. Czy to szaleństwo czy strategiczny ruch dla nowoczesnych organizacji?\nOdpowiedź, jak zwykle, brzmi: \u0026ldquo;to zależy\u0026rdquo;. Ale jedno jest pewne: wdrożenie baz danych na Kubernetesie wymaga zupełnie nowego podejścia!\nZapomnij o prostym \u0026ldquo;lift and shift\u0026rdquo; – to przepis na katastrofę. Bazy danych to nie bezstanowe aplikacje. Potrzebują troski, opieki i solidnych fundamentów. Dziś podzielę się z Tobą 5 kluczowymi zasadami, które musisz znać, jeśli chcesz to zrobić dobrze.\nBazy danych na Kubernetesie: Odwaga z rozwagą! Uruchamianie baz danych na Kubernetesie to krok w stronę automatyzacji, skalowalności i odporności. Ale to też wyzwanie. Musisz porzucić tradycyjne myślenie o bazach danych jako o monolitycznych bytach i przyjąć nową mentalność – baz danych jako usług, zarządzanych przez kod.\nJak to zrobić? Oto 5 żelaznych zasad:\nPostaw na operatory: Zapomnij o ręcznym konfigurowaniu, skalowaniu i backupach. Operatory to klucz do automatyzacji. Używaj ich do zarządzania provisioningiem, skalowaniem, backupami, upgrade\u0026rsquo;ami i wszystkimi innymi operacjami. I zapomnij o Helm Chartach!\nDo baz danych operatory to dużo lepsze rozwiązanie, bo oferują wyższy poziom abstrakcji i kontroli.\nAutomatyczne backupy ORAZ resty: Kopia zapasowa to nie wszystko. Musisz automatycznie testować integralność backupów! Ustaw automatyczne backupy i regularne testy odzyskiwania danych. Pamiętaj: backup, którego nie da się odtworzyć, jest bezużyteczny.\nO tym jak to można prosto uzyskać piszę poniżej 👇\nBezpieczeństwo to Podstawa: W Kubernetesie, jak i w życiu, bezpieczeństwo to nie opcja, to obowiązek. Stosuj ścisłą kontrolę dostępu, szyfruj dane i regularnie aktualizuj operatory. Implementuj zasadę least privilege.\nMonitoring i alertowanie: Śledź wydajność i zużycie zasobów bazy danych. Latency to Twój wróg! Proaktywnie identyfikuj i rozwiązuj potencjalne problemy. Skonfiguruj alerty, które powiadomią Cię o wszelkich anomaliach.\nZarządzanie zasobami ma znaczenie: Starannie skonfiguruj żądania zasobów (requests) i limity (limits) dla podów baz danych. Wybierz odpowiednią klasę QoS (Quality of Service). Guaranteed jest często najlepszym wyborem dla baz danych, bo zapewnia przewidywalną wydajność.\nPrawdziwi twardziele robią backupy ORAZ je testują Ostatnio w pewnym projekcie sam implementowałem testy backupu dla bazy danych na Kubernetesie. Powiem Ci, jak to było naprawdę proste dzięki operatorowi CloudNativePG (http://cloudnative-pg.io/)! To pokazuje, że automatyzacja w Kubernetesie naprawdę działa.\nJak to zrobić? U mnie wyglądało to tak:\nSkrypt w pythonie: Uruchamiany z CronJob codziennie po pełnym backupie. Tworzenie i odtwarzanie: Skrypt uruchamia tworzenie nowej bazy danych, czeka na jej odtworzenie z najnowszego backupu, który skrypt szuka po API na podstawie timestampów z odpowiedniego obiektu. Weryfikacja danych: Sprawdza zawartość bazy za pomocą zapytań SQL, aby upewnić się, że dane są poprawne. Wynik i Alerty: Skrypt kończy się sukcesem (status=0) lub błędem (status!=0). Dodatkowo monitoring wystawia alert w przypadku błędu - to na podstawie statusu Joba utworzonego przez CronJob. GitOps: Cała konfiguracja (skrypt, CronJob, monitoring) trzymana jest w jednym katalogu w repoi i zarządzana przez GitOps (Argo CD). To pokazuje, że testowanie backupów da się zautomatyzować i włączyć do workflow GitOps!\nCzy Warto Ryzykować? Wdrożenie baz danych na Kubernetesie to nie jest spacerek po parku. To wyzwanie, które wymaga wiedzy, doświadczenia i odpowiednich narzędzi. Ale korzyści – automatyzacja, skalowalność, odporność – są warte wysiłku. Pamiętaj jednak, że bez przestrzegania tych 5 zasad i testowania backupów, łatwo o spektakularną katastrofę.\nSpotkaj mnie na tych wydarzeniach Confidence (🔥 -15% rabatu z kodem \u0026ldquo;TEAM15\u0026rdquo; )\n🗓️ Kraków, 2-3 czerwca Temat: [EN] Hacking and Securing Kubernetes\nCloud Native Warsaw\n🗓️ Warszawa, 11 czerwca 18:00\nSzczegóły wkrótce\nDevoxx Poland\n🗓️ Kraków, 11-13 czerwca Temat: [EN] Synergy of GitOps and CI/CD pipelines\nIT Unplugged (🔥 -20% rabatu z kodem \u0026ldquo;CLOUDOWSKI20\u0026rdquo; )\n🗓️ Lublin, 10 czerwca\nTemat: [PL] Synergia GitOps i potoków CI/CD\n🗓️ Kalendarz szkoleń na żywo Sprawdź kalendarz szkoleń z dostępnymi terminami szkoleń, na których skupisz się na zrozumieniu trudnych tematów znajdziesz tutaj: https://cloudowski.com/training/#calendar\n","tags":["backupy","kubernetes","db","operatory"],"title":"Newsletter #132 - Tylko prawdziwi twardziele tak robią"},{"categories":null,"date":"May 16, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/why-bother/","section":"blog","summary":"\nAnd yet so many have tried and are still trying.\n","tags":["meme","automation"],"title":"Why bother?"},{"categories":null,"date":"May 14, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/28/","section":"podcast","summary":"Wracam z podcastem po dłuższej przerwie!\nPosłuchaj i dowiedz się z tego odcinka:\nDlaczego wracam Co się u mnie zmieniło Co zmieniam w podcaście Dla kogo będzie dalej ten podcast Co się stało z moim podejściem do AI Komentuj i daj mi znać kogo chcesz usłyszeć w tym podcaście, jakie tematy są teraz dla Ciebie istotne.\nLinki Kurs \u0026ldquo;AI w minutę\u0026rdquo; - https://ai.cloudowski.com Kurs \u0026ldquo;SkillBooster GitLab CI\u0026rdquo; - https://edu.cloudowski.com/product/skillbooster-gitlab-ci/ Migracja strony z Wordpress do Hugo - https://cloudowski.com/articles/how-ai-helped-me-to-migrate-my-website/ O certyfikacji kubestronaut - https://cloudowski.com/articles/how-to-get-certified-in-kubernetes-and-is-it-really-worth-it/ ","tags":["devops","ai","platformengineering"],"title":"28 - Dlaczego zrezygnowałem z AI"},{"categories":null,"date":"May 13, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/why-ai-can-generate-even-more-technical-debt/","section":"blog","summary":"I\u0026rsquo;ve seen how AI is creating new apps in a few minutes and it\u0026rsquo;s amazing! This is exciting, but there\u0026rsquo;s a big problem we need to talk about: technical debt.\nWe might be making things too easy, and creating a mess for the future.\nIt\u0026rsquo;s tempting to think that anyone can be a software developer now, thanks to AI. But while AI can generate code quickly, it doesn\u0026rsquo;t always create good code. It\u0026rsquo;s like building a house without a plan – it might look okay at first, but it could fall apart later.\nHere\u0026rsquo;s what happens:\nCode grows super fast: AI can generate a lot of code quickly, but this code can become complex. It becomes hard to maintain: The code can be hard to understand, change, and fix. No architecture: Good apps need a good plan (architecture). AI-generated code might not have this and may cause a lot of problems. It\u0026rsquo;s not just the first version: Making an app work at first is one thing. Keeping it working, changing it, and adding new features is another. That\u0026rsquo;s where technical debt hits you. AI is awesome, but it’s very easy to create new apps quickly which can, after some time turn out very poorly and hard to manage. More people start to believe they can become professional developers quickly, but this can lead to technical debt problem!\nIt’s easy to make something work the first time, but the real challenge is managing it afterwards.\nSo, what do you think? Is AI creating a technical debt crisis? Can AI code be well-architected and maintained in the long run? Maybe it\u0026rsquo;s just a matter of time before AI can do this too?\nShare your thoughts in the comments! 👇\n#AI #ArtificialIntelligence #TechnicalDebt #SoftwareDevelopment #CodeGeneration #DevOps #Architecture #MachineLearning #Programming #FutureOfWork\n","tags":["ai","experience","technicaldebt"],"title":"Why AI can generate even more technical debt"},{"categories":null,"date":"May 9, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/we-work-so-hard/","section":"blog","summary":"\nMaybe not many appreciate it, but we are going to automate even more anyway! 💪\n","tags":["meme","devops","automation"],"title":"We work so hard"},{"categories":null,"date":"May 8, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/the-ai-expertise-paradox/","section":"blog","summary":"We\u0026rsquo;re starting to see AI more realistically now, right? It\u0026rsquo;s not a magical fix-all, but a tool – a powerful one, but still a tool. And for some tasks, it can be incredibly useful.\nThere\u0026rsquo;s a common misconception, especially among those newer to a field, that AI can instantly unlock mastery of a completely unknown technology. It\u0026rsquo;s tempting to think AI will make everything effortless.\nHere\u0026rsquo;s the hard truth:\nThe more expertise you have, the more AI can help you.\nAI shines at automating repetitive tasks, generating initial drafts, and identifying patterns. It can significantly accelerate workflows if you already understand the fundamentals. Think of it as a force multiplier, not a replacement.\nThe human element remains crucial. We need to provide the context, requirements, examples, and constraints. We need to address AI\u0026rsquo;s limitations (like \u0026ldquo;hallucinations\u0026rdquo;) and guide it towards optimal solutions.\nIt is crucial to check whether AI is right and reasonable. AI often takes short route to be seen correct.\nSo, are you disappointed? I hope not! The reality is far more interesting. AI augments our abilities, it doesn\u0026rsquo;t replace them. How are you actually using AI in your daily work? What are the realistic benefits and challenges you\u0026rsquo;re seeing?\nAI is a fantastic co-pilot, but nothing will replace our thinking, core concepts, and the deep understanding we bring to the table. Let\u0026rsquo;s discuss in the comments! 👇\n#AI #ArtificialIntelligence #MachineLearning #DevOps #PlatformEngineering #Expertise #Automation #FutureOfWork #Technology #HumanInTheLoop\n","tags":["ai","automation"],"title":"The AI Expertise Paradox"},{"categories":null,"date":"May 6, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/why-kubernetes-is-so-complex/","section":"blog","summary":"Is Kubernetes giving you a headache? You\u0026rsquo;re not alone! It\u0026rsquo;s often described as complex, and there\u0026rsquo;s no denying there\u0026rsquo;s a learning curve. But there are reasons why some may find it complex and hard to comprehend.\nLet\u0026rsquo;s look at why it feels that way and how to overcome it:\n💡 It\u0026rsquo;s a System of Systems: Kubernetes isn\u0026rsquo;t just one tool; it\u0026rsquo;s an ecosystem. Learning requires understanding multiple components and how they interact. Networking, storage, security – it\u0026rsquo;s all integrated, and every connection adds the complexity.\n💡 Declarative vs. Imperative: Shifting from imperative commands to a declarative model (defining the desired state instead of how to get there) is a big leap for many. It’s like learning a new language, at first it might be complex but using new language you can express yourself better and more efficiently.\n💡 Abstraction Layers: Kubernetes abstracts away a lot of underlying infrastructure details. This is powerful but can make troubleshooting feel like working in a black box – but the advantage is huge productivity and simplicity.\n💡 The Pace of Evolution: The Kubernetes ecosystem is constantly evolving. New features, tools, and best practices emerge rapidly. It’s like a treadmill – you always need to improve!\n👉 To make it SIMPLE: Kubernetes can be seen a bunch of Linux servers managed through a unified API. That\u0026rsquo;s all it is!\nWhat was your biggest \u0026ldquo;aha!\u0026rdquo; moment with Kubernetes? What concepts clicked for you and made everything easier? Share your thoughts in the comments! 👇\n#Kubernetes #DevOps #CloudNative #K8s #Complexity #PlatformEngineering #Containers #Learning #Tips #AhaMoment\n","tags":["kubernetes"],"title":"Why Kubernetes is so complex?"},{"categories":null,"date":"May 5, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/131/","section":"newsletter-archive","summary":"Testowanie na produkcji\u0026hellip; brzmi jak przepis na katastrofę, prawda? W końcu ryzykujemy stabilność systemu i nerwy użytkowników. A co, jeśli powiem Ci, że testowanie na produkcji, (robione z głową), ma OGROMNE zalety?\nNie jest to metoda dla każdego systemu i każdej organizacji, ale w odpowiednich rękach staje się potężnym narzędziem w arsenale DevOps.\nTradycyjnie czyli nudno i mało dokładnie Dla tych, co lubią grać bezpiecznie, jest stary, dobry cykl: development -\u0026gt; testy -\u0026gt; staging -\u0026gt; produkcja.\nNudne, przewidywalne, wolne i co najważniejsze – często zawodne. No bo taki staging to tylko atrapa produkcji. Nigdy nie odda prawdziwego chaosu, prawdziwego ruchu czy prawdziwych danych.\nTestowanie na produkcji może być o wiele bardziej dokładne i z potencjałem na ogromny zysk.\nUzasadnione szaleństwo Może to brzmi jak akt desperacji, ale spójrz na to z perspektywy kogoś, kto nie boi się ryzyka i widzi takie oto korzyści:\nPrawdziwe dane: Chcesz prawdziwego feedbacku a nie udawanego z syntetycznych scenariuszy? Testowanie na produkcji to to testowanie na prawdziwym ruchu, prawdziwych dancy, bez żadnych filtrów. Szybszy feedback: Wdrażasz i od razu widzisz reakcję prawdziwego środowiska. Problemy, które się pojawią możesz wyłapać o wiele szybciej. Oszczędność kosztów: Środowisko staging? To czasem mnóstwo kasy na środowisko, które musi przypominać produkcję, a które się nudzi i nie jest wykorzystywane. Testowanie na produkcji ma duże ekonomiczne uzasadnienie. Oszczędzasz na środowiskach, a jako zwrot masz bardziej stabilny system. Szybsze wdrożenia: Takie feature toggles to wspaniały mechanizm, który w ułamku sekundy włączasz lub wyłączasz daną funkcjonalność. Testujesz, sprawdzasz i decydujesz bez konieczności zapuszczania potoków CI/CD oraz czekania na rolling update. Zasady dla rozważnych ryzykantów Jasne, to jest szaleństwo. Ale kontrolowane szaleństwo.\nTestowanie na produkcji wymaga ostrożności. Kluczowe zasady to:\nFeature Toggles: Fundament bezpieczeństwa. Używaj ich, aby kontrolować włączanie/wyłączanie funkcji, testować w izolacji i szybko wycofywać zmiany. Skuteczny monitoring: Monitoruj wydajność, błędy i doświadczenie użytkownika w czasie rzeczywistym. Skonfiguruj proaktywne alerty. Wdrażanie progresywne (Canary, A/B): Wdrażaj stopniowo, zaczynając od małej grupy użytkowników lub części infrastruktury. Obserwuj i analizuj wyniki przed pełnym wdrożeniem. Działający rollback: Miej gotowy i przetestowany plan automatycznego wycofania zmian na wypadek problemów. Najlepiej w połączeniu z GitOps, gdyż tak najlepiej wycofasz wszystkie zmiany. Pamiętaj: testowanie na produkcji wymaga dojrzałości i odpowiednich narzędzi. Stosując te zasady, minimalizujesz ryzyko i zyskujesz cenny feedback.\nSpotkaj mnie na tych wydarzeniach Confidence\n🗓️ Kraków, 2-3 czerwca (jeszcze nie wiem którego dnia)\nTemat: [EN] Hacking and Securibg Kubernetes\nCloud Native Warsaw\n🗓️ Warszawa, 11 czerwca 18:00\nSzczegóły wkrótce\nDevoxx Poland\n🗓️ Kraków, 11-13 czerwca (jeszcze nie wiem którego dnia)\nTemat: [EN] Synergy of GitOps and CI/CD pipelines\nIT Unplugged (🔥 -20% rabatu z kodem \u0026ldquo;CLOUDOWSKI20\u0026rdquo; )\n🗓️ Lublin, 10 czerwca\nTemat: [PL] Synergia GitOps i potoków CI/CD\n🗓️ Kalendarz szkoleń na żywo Sprawdź kalendarz szkoleń z dostępnymi terminami szkoleń, na których skupisz się na zrozumieniu trudnych tematów znajdziesz tutaj: https://cloudowski.com/training/#calendar\n","tags":["testing","canary","progressivedelivery"],"title":"Newsletter #131 - Czy jesteś wystarczająco szalony?"},{"categories":null,"date":"May 2, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/inconvenient-truth-about-observability/","section":"blog","summary":"\nI wish it wasn\u0026rsquo;t true 🙁\n","tags":["meme","observability"],"title":"Inconvenient truth about observability"},{"categories":null,"date":"May 1, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/confidence-conference-2025/","section":"blog","summary":"Did you know that your Kubernetres cluster could be vulnerable? Even with RBAC and continuous updates?\nKubernetes is universal and can support any type of application. However, this comes at a price. There are options that open the door for attackers and can make your environment vulnerable. In this presentation, I will show the importance of protecting pods with a built-in solution - Pod Security Admission.\nThe presentation includes a LIVE DEMO of an attack using really simple techniques and tools.\nCome to my presentation at Confidence 2025 to find out!\n👉 Use this special promo code to get 15% off your ticket: TEAM15\nTickets and details available on the event site: https://confidence-conference.org/\n","tags":["conferences","kubernetes","security"],"title":"See you at Confidence 2025"},{"categories":null,"date":"April 24, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/one-key-cicd-principle/","section":"blog","summary":"I’ve been designing and running CI/CD pipelines for a long time and there’s one principle that makes it so much easier. I wish I had learnt it earlier - it would have saved me so much time!\nWe\u0026rsquo;re spoiled for choice with amazing CI/CD engines these days! (Jenkins, GitLab CI, GitHub Actions, you name it). They\u0026rsquo;re packed with features, DSLs, plugins, and addons\u0026hellip; but sometimes, all that power actually makes things worse.\nThe big problem? Many pipelines treat every change as a full, linear run. Later stages depend on previous ones, making it super hard to iterate, debug, or even add unit tests!\nIt\u0026rsquo;s like a domino effect – one small tweak requires rerunning the entire thing.\nSo, what\u0026rsquo;s the solution? Keep it simple:\n👉 The core principle is to use your CI/CD engine for orchestrating independent steps – steps that could be launched locally, like shell or Python scripts.\nTreat the CI/CD system as an orchestrator, not a black box for everything.\nThink small, modular, and self-contained units. If you use container images, then ideally build process should be the same when run in CI/CD or on local machine.\nBy designing your pipelines this way, you gain massive flexibility, testability, and portability.\nWhat do you think? Is this the key to CI/CD sanity? What are your go-to principles for building maintainable pipelines? Share your thoughts in the comments! 👇\n","tags":["cicd","devops","jenkins","gitlab"],"title":"What is one CI/CD design principle that makes a huge difference?"},{"categories":null,"date":"April 22, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/are-databases-on-kubernetes-production-ready/","section":"blog","summary":"Is it a smart or dumb idea to entrust your data to containers and Kubernetes? It\u0026rsquo;s not just lifting and shifting; you need a new mindset!\nImplementing databases on Kuberbetes requires a careful approach.\nHere are essential best practices:\n✅ Embrace Operators: Automate provisioning, scaling, backups, and upgrades. Don\u0026rsquo;t use Helm Charts!\n✅ Automated Backups AND Tests: Implement automated backups, and schedule automated tests to validate backup integrity! It\u0026rsquo;s no good having backups if you can\u0026rsquo;t restore them!\n✅ Security is Non-Negotiable: Strict access control, encryption, and regular patching. Implement least privilege.\n✅ Monitoring and Alerting: Track performance and resources. Proactively identify and address potential issues. Latency is your enemy!\n✅ Prioritize Resource Management: Carefully configure resource requests/limits, and choose an appropriate QoS class (Guaranteed is often best!) for database pods to ensure predictable performance. Use resource quotas to limit consumption by database instances.\nAre you contemplating running your database on Kubernetes? Is it worth the complexity? Are you actually testing your backups regularly? Or is using a managed database service a better choice? What do you think?\n","tags":["databases","kubernetes"],"title":"Are Databases on Kubernetes production-ready?"},{"categories":null,"date":"April 22, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/130/","section":"newsletter-archive","summary":"Oj, nieźle się porobiło! W światku Kubernetesowym zawrzało po ujawnieniu poważnej luki w popularnym kontrolerze ingress-nginx. Wtopa jest konkretna, ale spokojnie, bez paniki!\nDziś o tej podatności, o konferencjach gdzie mnie możesz spotkać i szkoleniach na żywo.\nLuka w ingress-nginx Firma Wiz, specjalizująca się w cloud security, wygrzebała niezłą minę – zestaw poważnych luk w ingress-nginx. Mówimy o kontrolerze, którego używa 40% środowisk chmurowych (według Wiz).\nGłówny problem (CVE-2025-1974) siedzi w admission controllerze ingress-nginx i uwaga – ta podatność drzemała tam niemal od początku projektu! Szok? No pewnie!\nCzy łatwo jest wykorzystać tą lukę? Na szczęście exploit nie jest banalny i wymaga spełnienia pewnych warunków. Atakujący musi już mieć dostęp do klastra Kubernetes, który pozwoli mu gadać z podem ingress-nginx przez Service.\nAle to nie wszystko! Atakujący potrzebuje dodatkowej wiedzy i zasobów, np. umiejętności napisania specjalnej biblioteki współdzielonej, żeby zyskać shell w ingress-nginx. Wiz team co prawda pokazał demo exploita na krótkim filmiku, ale pełnego skryptu nie udostępnili.\nCzyli potencjalni napastnicy muszą sami się natrudzić, żeby stworzyć działający exploit. Może być to jednak prostsze z dzisiejszymi narzędziami AI, a zatem koniecznie trzeba się zabezpieczyć.\nJak się obronić Na szczęście lekarstwo jest banalnie proste: aktualizacja ingress-nginx.\nNajważniejsze to jak najszybciej zaktualizować ingress-nginx do najnowszej, załatanej wersji. Instrukcje aktualizacji znajdziesz w oficjalnej dokumentacji dla Twojego sposobu wdrożenia (Helm, manifesty, etc.).\nPo szczegóły i lekcje na przyszłość odsyłam do mojego artykułu: https://cloudowski.com/articles/how-critical-is-the-ingress-nginx-vulnerability/\nSpotkaj mnie na tych konferencjach Confidence\n🗓️ Kraków, 2-3 czerwca (jeszcze nie wiem którego dnia)\nTemat: [EN] Hacking and Securibg Kubernetes\nDevoxx Poland\n🗓️ Kraków, 11-13 czerwca (jeszcze nie wiem którego dnia)\nTemat: [EN] Synergy of GitOps and CI/CD pipelines\nIT Unplugged (🔥 -20% z kodem \u0026ldquo;CLOUDOWSKI20\u0026rdquo; )\n🗓️ Lublin, 10 czerwca\nTemat: [PL] Synergia GitOps i potoków CI/CD\n🗓️ Kalendarz szkoleń na żywo Dla tych co pytają o szkolenia na żywo mam dobrą wiadomość. Właśnie opublikowałem kalendarz szkoleń z dostępnymi terminami.\nTo okazja, aby w dedykowanym czasie skupić się na zrozumieniu jak to wszystko działa, dopytać o szczegóły, przetestować, czasem pobłądzić i zadać trudne pytania.\n👉 Sprawdź szczegóły na stronie: https://cloudowski.com/training/#calendar\n","tags":["ingress","nginx","security"],"title":"Newsletter #130 - Ale wtopa z tym ingressem"},{"categories":null,"date":"April 14, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/why-is-breaking-the-platform-good-thing/","section":"blog","summary":"Good platform teams care about reliability. Excellent teams experiment and break things in order to learn and improve. It might seem counterintuitive to actively try to cause problems, but it\u0026rsquo;s the most effective way to build resilience.\nChaos Engineering isn\u0026rsquo;t about randomly causing chaos. It\u0026rsquo;s about thoughtfully planning experiments to test your system\u0026rsquo;s ability to withstand failures.\nBy proactively injecting faults (e.g., killing pods, delaying network traffic, simulating disk failures), you can uncover weaknesses you never knew existed.\nThink of it like stress-testing a bridge. You wouldn\u0026rsquo;t wait for a real earthquake to see if it can withstand the forces. You\u0026rsquo;d simulate the earthquake in a controlled environment. Chaos Engineering does the same for your platform.\nBreaking things in production (in a controlled manner!) allows you to:\n✅ Identify Hidden Dependencies: Uncover unexpected connections between services\n✅ Validate Your Monitoring: Ensure your alerts fire when they\u0026rsquo;re supposed to\n✅ Improve Your Response Procedures: Practice responding to real-world failures\n✅ Build a More Resilient System: Learn from your mistakes and make your platform stronger\nStart small, automate your experiments, and always have a rollback plan. Remember - don\u0026rsquo;t break production by accident, always on purpose!\nWhat are your thoughts on chaos engineering?\nAre you actively experimenting with failure scenarios in your platform? I\u0026rsquo;m curious to hear about your experiences – the good, the bad, and the unexpected.\n","tags":["chaosengineering","platformengineering","devops","reliability"],"title":"Why is breaking the platform a good thing?"},{"categories":null,"date":"April 10, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/how-to-prevent-kubernetes-vulnerabilities/","section":"blog","summary":"Did the recent ingress-nginx vulnerability (CVSS 9.8!) send shivers down your spine? 😱 Patching is crucial, but the real lesson is how to prepare for the next inevitable flaw.\nMy latest article breaks down the vulnerability and shares 5 essential lessons to harden your Kubernetes clusters before disaster strikes. Learn why:\n1️⃣ Restricting egress traffic matters\n2️⃣ GitOps isn\u0026rsquo;t just trendy, it\u0026rsquo;s a security principle\n3️⃣ Shells in container are risky\n4️⃣ Trusted images are non-negotiable\n5️⃣ Everything-as-Code is your best defense\nDon\u0026rsquo;t just react – build resilience.\n","tags":["security","devsecops"],"title":"How to prevent vulnerabilities like ingress-nginx in the future?"},{"categories":null,"date":"April 8, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/solutions/platform-evolution-roadmap/","section":"solutions","summary":"\nWhat is a Platform? A platform is a complete environment able to run all kinds of applications.\nModern platform these days is based on containers and Kubernetes (or OpenShift) running in the cloud, on on-premises hardware or in hybrid environments.\nTo provide necessary features, multiple Cloud Native technologies are used to accomplish high reliability, security and scalability.\nTogether with Platform Engineering and DevOps practices, the platform built within the organization makes it possible to develop and manage almost any software in a cost-effective manner.\nWhat are Platform Maturity Levels? The five levels are distinguished stages of implementation of a specific subset of features. These features increase capabilities of the platform in an incremental manner.\nEach level includes strategies for achieving a specific level of maturity to provide more confidence in the platform and allows for running more critical software.\nWhy is this level-based approach better? This approach is more evolutionary rather than revolutionary. It’s more practical and takes into account the time needed for learning new tools and processes.\nIt also allows the platform\u0026rsquo;s capabilities to be better aligned with the organization\u0026rsquo;s context (e.g. existing software, policies, restrictions, etc.).\nEach level can introduce or extend the use of particular practice or technology (e.g. GitOps, Zero Trust Environment, Progressive Delivery, Chaos Engineering etc.) at a different advancement level.\nLevel 1 - The Launchpad Provide a good enough starting point for experimentation.\nThe sooner the platform is available, the better. Start with rudimentary features to enable first applications to leverage the speed and flexibility of Kubernetes.\nUse this level only as a starting point to experiment and test the possibilities. Be prepared for a rather reactive approach to problems and manual actions to fix them.\nThe time will come for more advanced means of improvement.\nRequirements ✅ A budget for the work to set up the platform and to deploy first applications\n✅ Access to the cloud with Kubernetes service or available on-prem resources\n✅ A team with skills for setting up the platform (greater for on-prem environments)\nFor whom → Every organization starting the journey (non-prod!)\nBenefits Enables developers to learn and use Kubernetes and containers Enables more advanced developers to leverage already built and used container images in a scale (previously locally) Enables operations team to learn and discover how to create more mature platform with the available infrastructure (cloud providers or on-prem) Allows for flexibility of adding more advanced options (i.e. additional products or services enhancing the platform features) before running real production workloads Development and operations teams gain more experience Practices and Techniques Security Unrestricted Container Runtime\nBasic Access Management\nBasic Secrets Management\nEfficiency Manual Application Scaling\nUnmanaged Cluster Resources\nDelivery Basic Delivery Processes\nBasic Build Processes\nBasic Deployment Management\nAvailability Kubernetes Built-in Resiliency\nDo ➕ Choose fast paths, even if they are now considered imperfect\n➕ Find and encourage technology enthusiasts to participate\n➕ Run your applications to align the platform use to the context\nDon\u0026rsquo;t ➖ Implement more advanced features (e.g. RBAC, GitOps, Persistent Volumes)\n➖ Focus on scalability or security\n➖ Automate processes of building container images, delivery or platform provisioning\nLevel 2 - Operational Foundation Discover useful features and explore further.\nLet people continue to learn while the platform is improved and more features are added.\nA small number of non-critical, stateless applications may run to prove the usability and benefits of using the new approach.\nRequirements ✅ A small number of applications is ready for first production\n✅ Basic roadmap with a set of applications to run on the platform\n✅ Permission to learn and experiment with the delivery process\n✅ Selected most important components (i.e. cloud provider, Kubernetes distribution, cluster architecture)\n✅ Confirmed (or disconfirmed) usability of the new approach for the company - decision to move forward or stop and analyze\nFor whom → Every organization that wants to build more mature and professional platform\n→ Companies (e.g. startups) choosing to make non-critical services available to clients\nBenefits Increased security rules to protect the applications and the platform Increased visibility of platform performance and operations Faster and more frequent deployments with rollbacks Reduced response time and handle peak traffic with manual scaling Enable developers to use of Kubernetes and containers Ready for non-critical production workloads (small scale, small risk, stateless) Practices and Techniques Security Unrestricted Container Runtime\nBasic Access Management\nBasic Secrets Management\nBasic Cluster Updates\nBasic Traffic Filtering\nBasic Vulnerabilities Management\nEfficiency Manual Application Scaling\nBasic Resources Management\nDelivery Basic Delivery Processes\nBasic Build Processes\nBasic Deployment Management\nAvailability Hard multi-tenancy\nBasic Platform Monitoring\nDo ➕ Choose the necessary services or products (Kubernetes distribution, logging, identity)\n➕ Address doubts about platform capabilities with open communication\n➕ Implement basic security rules\nDon\u0026rsquo;t ➖ Force migration of existing, non-containerized applications\n➖ Optimize infrastructure costs (yet)\n➖ Standardize and unify delivery processes\nLevel 3 - Data-Driven Improvement Learn and improve using reliable data.\nThe first semi-critical applications can run on in production. It\u0026rsquo;s time to rely on the data collected on the platform to improve security, simplify troubleshooting, and reduce infrastructure costs.\nAt this level, more experience is required to leverage the potential of Kubernetes and Cloud Native projects.\nRequirements ✅ Some apps work in prod to prove the readiness of platform\n✅ Some standards have emerged (delivery)\n✅ More skilled platform team(s)\nFor whom → Preparing for more critical use\n→ More security required\n→ Availability becomes more critical\nBenefits More reliable platform (at least 99.9%) Reduced risk of data leaks Possible to scale both workloads and platform Optimized utilization of resources More people trust the provisioned platform Practices and Techniques Security Basic Secrets Management\nBasic Traffic Filtering\nBasic Vulnerabilities Management\nShift Left Security\nRestricted Container Runtime\nAdvanced Vulnerabilities Management\nAdvanced Data Protection\nEfficiency Basic Application Autoscaling\nAdvanced Application Autoscaling\nCluster Autoscaling\nBasic Resources Management\nDelivery Basic Delivery Processes\nDORA Metrics\nGolden Paths\nAdvanced Build Processes\nAdvanced Deployment Management\nAdvanced Delivery Processes\nAvailability Hard multi-tenancy\nAdvanced Platform Monitoring\nAutomated Node Provisioning\nContinuous Resiliency Improvement\nManual Disaster Recovery Testing\nApplication Observability\nPlatform Observability\nBasic Disaster Recovery\nDo ➕ Start implementing best practices in code (security rules, delivery pipelines, etc.)\n➕ Create a dedicated team for managing the platform\n➕ Improve platform capabilities based on data\nDon’t ➖ Force GitOps for all processes\n➖ Delegate platform security to a dedicated team\n➖ Run stateful applications on the platform (yet)\nLevel 4 - Productized Platform Manage platform with an “Everything as Code” approach.\nThe platform is now fully automated and improvements are being implemented in code (GitOps).\nMore proactive and automated measures are being used to improve application reliability, scalability and address security threats.\nRequirements ✅ Large scale to justify higher costs\n✅ Dedicated platform team or teams to manage the platform\nFor whom → Organizations with large scale apps\n→ Organizations with many stateful services\n→ Organizations with compliance standards requirements (e.g. GDPR, PCI DSS, HIPAA)\nBenefits More reliable platform (at least 99.99%) Rapid delivery of more secure and reliable apps Faster and optimized scaling capabilities Infrastructure costs under control and available for optimization Significantly reduced risks of data leaks and break-ins Platform viewed internally as an essential service Practices and Techniques Security Shift Left Security\nRestricted Container Runtime\nAdvanced Vulnerabilities Management\nAdvanced Data Protection\nGitOps Platform Management\nPlatform Access Auditing\nAll traffic encrypted\nAdvanced Workloads Auditing\nCompliance Policies Enforcement\nAdvanced Traffic Filtering\nEfficiency Advanced Application Autoscaling\nCluster Autoscaling\nAdvanced Volume Management\nAdvanced Resources Management\nCosts Center Management\nPlatform Landing Zones\nDelivery DORA Metrics\nGolden Paths\nAdvanced Build Processes\nAdvanced Deployment Management\nAdvanced Delivery Processes\nExtended Images Build Processes\nGitOps Application Management\nExtended Delivery Processes\nAvailability Hard multi-tenancy\nAdvanced Platform Monitoring\nAutomated Node Provisioning\nContinuous Resiliency Improvement\nManual Disaster Recovery Testing\nApplication Observability\nPlatform Observability\nBasic Disaster Recovery\nDisaster Recovery for Persistent Storage\nChaos Engineering (non-prod)\nAdvanced Disaster Recovery Testing\nError Budget Management\nGitOps Platform Management\nFault-tolerant Workload Distribution\nDo ➕ Start treating the platform as an internal product\n➕ Tighten platform security rules\n➕ Improve platform capabilities based on data\nDon’t ➖ Announce the platform’s SLA (yet)\n➖ Stop people from testing and experimenting (in safe environments)\n➖ Rely on a single infrastructure provider (or datacenter)\nLevel 5 - AI-Ready Enterprise Platform Operate a strategic, continuously optimized platform capable of handling all enterprise workloads, including demanding AI/ML initiatives.\nThis represents the pinnacle of platform maturity.\nNo longer just infrastructure, the platform operates as a strategic internal product with defined SLAs, capable of reliably and efficiently running the organization\u0026rsquo;s most critical applications – from standard stateless services and stateful databases to complex, resource-intensive AI/ML training and inference workloads.\nRequirements ✅ Organization\u0026rsquo;s strategy to include continuous development and maintenance of the platform (software costs, people)\nFor whom → Highest requirements for platform security, reliability and cost effectiveness\nBenefits Implemented Zero Trust Environment Platform as a product with defined SLA Capabilities to run any type of workloads (stateless, stateful, machine learning, serverless) Detailed insight into the cost of operating the platform and application High confidence in the platform\u0026rsquo;s capabilities and reliability Practices and Techniques Security Advanced Access Management\nRestricted Container Runtime\nShift Left Security\nAdvanced Data Protection\nAdvanced Vulnerabilities Management\nGitOps Platform Management\nPlatform Access Auditing\nAll traffic encrypted\nAdvanced Workloads Auditing\nCompliance Policies Enforcement\nAdvanced Traffic Filtering\nIdentity-based Access Control\nZero Trust Environment\nNetwork Traffic Auditing\nEfficiency Advanced Application Autoscaling\nCluster Autoscaling\nAdvanced Volume Management\nAdvanced Resources Management\nCosts Center Management\nPlatform Landing Zones\nAdvanced Costs Management\nJust-in-time Capacity\nDelivery DORA Metrics\nGolden Paths\nAdvanced Build Processes\nAdvanced Deployment Management\nAdvanced Delivery Processes\nExtended Images Build Processes\nGitOps Application Management\nExtended Delivery Processes\nKubernetes Landing Zone\nInternal Developer Platform\nAvailability Hard multi-tenancy\nAdvanced Platform Monitoring\nAutomated Node Provisioning\nContinuous Resiliency Improvement\nManual Disaster Recovery Testing\nApplication Observability\nPlatform Observability\nBasic Disaster Recovery\nDisaster Recovery for Persistent Storage\nChaos Engineering (non-prod)\nAdvanced Disaster Recovery Testing\nError Budget Management\nGitOps Platform Management\nFault-tolerant Workload Distribution\nPlatform SLA\nChaos Engineering in Production\nMulti-cluster Platform\nDo ➕ Prepare and announce the platform’s SLA\n➕ Receive the official confirmation of platform compliance with security standards\n➕ Encourage people to run all their workloads on the platform\nDon’t ➖ Stop improving the platform\nReady for the Next Level? Understanding the stages of platform maturity provides a valuable map for your organization\u0026rsquo;s journey. You can now pinpoint your current location, whether you\u0026rsquo;re establishing foundational capabilities or optimizing existing processes.\nIt\u0026rsquo;s important to recognize that while Level 2 or even Level 3 offers a starting point and proves initial value, it\u0026rsquo;s generally insufficient for running critical applications reliably or securely in the long term.\nContinuing the evolution is crucial for sustainable success.\nFor many organizations, achieving Level 4 represents a powerful and sufficient end state. Reaching this level signifies a highly automated, secure, and reliable platform managed effectively through code, capable of handling complex and stateful workloads with confidence.\nIt\u0026rsquo;s a significant accomplishment that delivers substantial business value.\nHowever, for organizations aiming for the absolute leading edge, especially those heavily investing in AI/ML or operating with the highest demands for resilience, efficiency, and strategic agility, Level 5 represents the next frontier.\nThis level transforms the platform into a core strategic asset, fully optimized for any workload, including the most demanding AI initiatives. It embodies Zero Trust security, advanced cost control, and practices like production Chaos Engineering.\nWhile achieving Level 5 requires a significant commitment, it provides a future-proof foundation, maximizing innovation potential and offering unparalleled capabilities. Investing resources to reach this stage unlocks clear, long-term benefits and a distinct competitive advantage.\nIf you\u0026rsquo;d like to discuss your platform\u0026rsquo;s current maturity, evaluate the benefits and requirements of advancing, or strategize the most effective path forward – whether your target is Level 4 or the pursuit of Level 5 – I\u0026rsquo;m available to share insights and help you navigate your unique platform evolution.\n","tags":["platformengineering","devops","kubernetes","gitops","ai","architecture","strategy"],"title":"Platform Evolution Roadmap: 5 Stages of Maturity"},{"categories":null,"date":"April 8, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/testing-in-production-dumb-or-smart/","section":"blog","summary":"Testing in production\u0026hellip; sounds crazy, right? It turns out that testing in production (when done right!) offers huge advantages. It\u0026rsquo;s not for every team or every feature, but it\u0026rsquo;s a powerful tool in the right hands.\nThe traditional cycle of dev, test, staging, then prod is slow and often inaccurate. Test environments are never a perfect replica of production, leading to surprises after release. Testing in prod gives you invaluable real-world feedback, faster.\nHere\u0026rsquo;s why you might consider it:\n✅ Real Traffic, Real Data: Forget synthetic tests – get genuine user behavior\n✅ Rapid Feedback: Iterate quickly based on real-world use\n✅ Cost Effective: No need for expensive, mirrored environments\n✅ Faster Rollouts: Feature toggles enable instant activation/deactivation\nOf course, there are risks. Use feature toggles to easily disable new features. Monitor aggressively for errors. Start with a small subset of users (A/B testing, canary releases). Have a rollback plan ready.\nAre you brave enough to test in prod? Or does it sound like utter madness? Is it worth to risk production availability? What\u0026rsquo;s your experience?\n","tags":["security","devsecops"],"title":"Test in Production: Dumb or Smart?"},{"categories":null,"date":"April 3, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/sboms-incoming-are-you-ready/","section":"blog","summary":"⚠️ Did you know that generating SBOMs is or will be mandatory for some projects in the 🇺🇸 and 🇪🇺? It is important to implement SBOMs to keep your environment secure.\nSoftware Bill of Materials is required for some US projects as a consequence of “Executive order 14028\u0026quot;. In the EU it will be enforced by the EU Cyber Resilience Act (CRA).\nSBOM gives you more transparency and security across your components. Also keep in mind, that SBOM alone is not enough, and it needs to be followed with automated actions.\nAn SBOM is essentially a list of all the ingredients that make up your software – components, libraries, dependencies, etc. It\u0026rsquo;s like a nutrition label for your software.\nImplementing SBOM generation and management can seem daunting, but it\u0026rsquo;s becoming an essential practice.\n👉 Take a look at my “Kubernetes Deployment Factory” solution, where this is an integral part of the solution\u0026rsquo;s security: https://cloudowski.com/solutions/kubernetes-deployment-factory/\n","tags":["cicd","security","devsecops"],"title":"SBOMs Incoming! Are You Ready?"},{"categories":["blog"],"date":"April 1, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/bare-metal-or-virtualized-nodes/","section":"blog","summary":"What to choose for an on-prem platform - bare-metal or virtualized nodes? Of course there is one answer. It depends.\n💡 I would choose virtualized nodes only when I already have an existing virtualization infrastructure and for small/medium size environments. It provides some additional flexibility. Allows provisioning of nodes via API, which is faster and simpler (provided it’s supported by Kubernetes/OpenShift provisioning software).\nIt can increase reliability by minimizing the impact of hardware failure.\n💡 I would choose bare-metal nodes for larger environments. It doesn’t make sense to pay for virtualization software or introduce this abstraction layer when your software runs in ephemeral containers.\nThis mode requires more expertise in node provisioning, but it’s worth the time investment when there are hundreds of nodes. Did I mention that they can be quite cheap too, as they are ephemeral too and are easily replaceable?\n🤔 How about your case? Do you really need a virtualization layer for your platform? What are you running, and why? I\u0026rsquo;m curious to hear your thoughts.\nIf you\u0026rsquo;re weighing the pros and cons of bare-metal vs. virtualized nodes for your platform and want to explore the best fit for your specific situation, I\u0026rsquo;m happy to share some insights.\n","tags":["platformengineering","virtualization","performance"],"title":"Bare-metal or Virtualized nodes?"},{"categories":["newsletter"],"date":"April 1, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/129/","section":"newsletter-archive","summary":"Dzisiaj chwilę o Jenkinsie - rozwiązaniu pamiętającym czasy sprzed kontenerów i Kubernetesa. Okazuje się, że budzi to wciąż duże kontrowersje i postanowiłem przypomnieć tutaj jak można tego rozwiązania użyć w nowoczesnym stylu.\nJak czytasz ten newsletter to ja jestem już w drodze na KubeCon EU w Londynie. Jeśli też tam pkanujesz być to zapraszam w czwartek między 13 a 14:30 do pawilionu na poziomie 1 (wejście N8-N9), gdzie będę ze współorganizatorami KCD Warsaw promował naszą konferencję.\nJenkins - a na co to komu? Ach, Jenkins\u0026hellip; Samo wspomnienie tej nazwy potrafi wywołać skrajne emocje w świecie DevOps. Jedni najchętniej widzieliby go już dawno na cyfrowym cmentarzu, a inni bronią go jak niepodległości.\nPrawda jest taka, że mimo swojego wieku i pewnych problemach, Jenkins wciąż jest obecny w wielu firmach. I co więcej – może być całkiem pomocnym narzędziem. Kluczem jest jednak odpowiednie zarządzanie nim. Zapomnij jednak o klikaniu w interfejsie i ręcznych aktualizacjach.\nNie da się ukryć, że Jenkins ma swoje lata. Jego potężny ekosystem pluginów to jednocześnie największa siła i największa słabość. Z jednej strony pozwala na ogromną elastyczność, z drugiej – nieumiejętne zarządzanie nimi prowadzi do chaosu, problemów z zależnościami (\u0026ldquo;plugin dependency hell\u0026rdquo;) i koszmarów podczas aktualizacji.\nDodajmy do tego często przestarzały interfejs i mamy gotowy przepis na frustrację zespołu. Nic dziwnego, że nowsze, bardziej zintegrowane i często prostsze w zarządzaniu narzędzia jak GitLab CI, GitHub Actions czy Tekton kuszą obietnicą łatwiejszego życia. Ale czy na pewno trzeba od razu wyrzucać Jenkinsa na śmietnik?\n5 zasad, które pozwalają ujarzmić Jenkinsa Jeśli już masz Jenkinsa lub z jakiegoś powodu musisz z niego korzystać, to mam dla Ciebie dobrą wiadomość – da się go okiełznać i sprawić, by działał elastycznie, niezawodnie i wydajnie. Wystarczy trzymać się kilku żelaznych zasad:\n1. Uruchamiaj go w kontenerze (najlepiej na Kubernetesie): Zapomnij o instalacji Jenkinsa bezpośrednio na maszynie. Konteneryzacja to absolutna podstawa. Ułatwia zarządzanie wersjami, wdrażanie, skalowanie i zapewnia spójność środowisk. Uruchomienie na Kubernetesie daje dodatkowe korzyści w postaci łatwego zarządzania zasobami i wysokiej dostępności.\n2. Aktualizuj pluginy TYLKO przez przebudowę i testowanie nowego obrazu: To jedna z najważniejszych zasad! Koniec z klikaniem \u0026ldquo;update\u0026rdquo; w interfejsie i modlitwą, żeby nic się nie zepsuło. Wszelkie zmiany w pluginach (instalacja, aktualizacja, usuwanie) powinny odbywać się przez modyfikację definicji obrazu kontenera, jego przebudowę i przetestowanie przed wdrożeniem na produkcję. Daje to kontrolę, powtarzalność i możliwość łatwego powrotu do poprzedniej wersji.\n3. Używaj wielu instancji (sharding): Jeden, wielki Jenkins obsługujący całą firmę to proszenie się o kłopoty. Staje się on wąskim gardłem i pojedynczym punktem awarii (single point of failure). Znacznie lepszym podejściem jest \u0026ldquo;sharding\u0026rdquo;, czyli dzielenie Jenkinsa na mniejsze, niezależne instancje dedykowane np. konkretnym zespołom, działom, środowiskom czy projektom. Zmniejsza to \u0026ldquo;blast radius\u0026rdquo; (zasięg awarii) i ułatwia zarządzanie.\n4. Używaj dynamicznie tworzonych podów jako workerów (przez plugin Kubernetes): Czasy statycznych agentów Jenkinsa (workerów) powinny odejść w zapomnienie. Ciągłe utrzymywanie maszyn, które przez większość czasu stoją bezczynnie, jest nieefektywne i kosztowne. Dzięki pluginowi Kubernetes, Jenkins może dynamicznie tworzyć pody w klastrze K8s na potrzeby konkretnego joba i usuwać je po zakończeniu pracy. To czysta oszczędność zasobów i zawsze świeże środowisko budowania.\n5. Zarządzaj jobami, konfiguracją i dostępem WYŁĄCZNIE jako kod (JCasC): Ręczna konfiguracja przez interfejs webowy to źródło problemów z \u0026ldquo;configuration drift\u0026rdquo; (rozjeżdżaniem się konfiguracji) i brakiem powtarzalności. Cała konfiguracja Jenkinsa – od ustawień systemowych, przez joby (np. Pipeline as Code), po zarządzanie uprawnieniami – powinna być zdefiniowana w kodzie i przechowywana w repozytorium Git. Narzędzie takie jak JCasC (Jenkins Configuration as Code) jest tutaj nieocenione. To umożliwia wersjonowanie, audytowanie, automatyzację i stosowanie praktyk GitOps.\nMoże to brzmi jak dużo pracy, ale zapewniam Was – gra jest warta świeczki. Sam widziałem (i pomagałem wdrażać) takie konfiguracje w wielu firmach. Jenkins zarządzany zgodnie z tymi zasadami staje się dojrzałym, niezawodnym i wciąż bardzo potężnym elementem platformy do dostarczania oprogramowania.\nJasne, może nie jest tak \u0026ldquo;sexy\u0026rdquo; jak najnowsze narzędzia, ale potrafi dobrze wykonywać swoją pracę.\nJeśli jednak wolisz coś nowoczesnego\u0026hellip; \u0026hellip; to sprawdź mój kurs GitLab CI. Specjalnie dla tych co nie lubią się z Jenkinsem przygotowałem kod zniżkowy JENKINS_IS_DEAD, który włącza rabat -100pln.\n⏰ Ważne tylko do końca tygodnia (do niedzieli 6 kwietnia)!\n","tags":["newsletter","jenkins","cicd"],"title":"Newsletter #129 - Czy Jenkins już umarł?"},{"categories":["blog"],"date":"March 28, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/expert-or-imposter/","section":"blog","summary":"How to distinguish a real Platform Expert from a fake one? The latter knows all the answers, the former asks the right questions. It sounds simple, but it\u0026rsquo;s a critical distinction.\nContext matters. The culture of an organization matters. Existing solutions matter, even if considered legacy. A true expert understands this.\nNot everything must run on Kubernetes. Not every problem can be fixed with (new) technology. And no company is Google except Google. These are the humbling truths a seasoned expert acknowledges.\nA real expert will:\n✅ Listen more than they talk\n✅ Consider existing constraints\n✅ Prioritize business value over shiny new tools\n✅ Admit what they don\u0026rsquo;t know\n✅ Ask questions!\nFake experts offer simplistic solutions and ignore the complexities of the real world. Real experts guide you through them.\n","tags":["expert","platformengineering","devops"],"title":"Expert or Imposter?"},{"categories":["blog"],"date":"March 28, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/lets-meet-at-kubecon-eu-2025/","section":"blog","summary":"London calling! 🇬🇧 Excited to be heading to KubeCon EU 2025!\nI\u0026rsquo;m really looking forward to seeing how the community has evolved and diving into some insightful talks. Most of all, I\u0026rsquo;d love to connect with fellow cloud native enthusiasts!\nWant to chat about Kubernetes, platform engineering, or anything cloud native? DM me if you\u0026rsquo;d like to meet up at the conference or at one of the parties!\nYou can also find me at:\n🗓️ Thursday 7:30am - I\u0026rsquo;m attending KCD Organizer Breakfast\n🗓️ Thursday 1:30pm-3:00pm - I\u0026rsquo;ll be at Project Pavilion - come say hi to me and the awesome KCD Warsaw team as we promote our conference\nSee you there!\n","tags":["conferences"],"title":"Let's meet at KubeCon EU 2025"},{"categories":null,"date":"March 27, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/how-critical-is-the-ingress-nginx-vulnerability/","section":"articles","summary":"Recently, the cloud security company Wiz disclosed a significant set of vulnerabilities affecting the popular Kubernetes ingress-nginx controller. Given its widespread use, understanding the risk and necessary actions is crucial for Kubernetes administrators and security teams. This article breaks down the vulnerability, its potential impact, how to exploit it, and, most importantly, how to fix it and learn from it.\nWhat is the Vulnerability? Discovered by the Wiz Research Team, the core issue (tracked primarily as CVE-2025-1974 lies within the admission controller part of ingress-nginx. Shockingly, it seems this vulnerability has existed almost since the beginning of the project!\nFor a deep dive into the technical specifics, refer to the detailed write-up by Wiz.\nHow Can It Be Exploited? Exploiting this vulnerability isn\u0026rsquo;t trivial and requires specific prerequisites:\nCluster API Access: The attacker must already have some level of access within the Kubernetes cluster that allows them to communicate with a ingress-nginx pod via its Service. This could be achieved through: Gaining shell access to an existing pod running in the cluster. Deploying a new pod from a special container image with malicious commands defined (either in the pod spec or within the container image\u0026rsquo;s entrypoint). Additional expertise and resources: The attacker might need the ability to write a specific shared library that is required to gain shell access from within a ingress-nginx, which requires further permissions or vulnerabilities. The Wiz team demonstrated a potential exploit path in a short video, but they have not published the full exploit script. This means attackers need to develop their own specific exploit based on the vulnerability details. How Critical Is It? ⚠️ Extremely critical. Here are the reasons:\nCVSS Score: The vulnerability carries a CVSS v3.1 base score of 9.8 (Critical). Scores this high indicate a severe vulnerability that is relatively easy to exploit (assuming the prerequisites are met) and has a significant impact. Prevalence: According to Wiz, over 40% of cloud environments might be running a vulnerable version of ingress-nginx. This widespread exposure makes the potential impact massive. Potential Impact: A successful attacker gains the permissions associated with the ingress-nginx controller itself. This typically includes the ability to: Read all Services: Discover internal network topology and potentially find other vulnerable services. Read all ConfigMaps: Access potentially sensitive configuration data. 🔴 (The Worst Part) Read all Secrets: This is the most damaging outcome. An attacker gaining access to all Kubernetes secrets within the cluster (API keys, database credentials, tokens, etc.) can lead to a complete cluster compromise and potentially spread to other systems. How to Fix It Mitigation is relatively straightforward:\nUpdate ingress-nginx: The primary fix is to update your ingress-nginx controller to the latest patched version. Follow the official upgrade guide for your deployment method (Helm, manifests, etc.). Temporary Workaround (If Update Is Impossible): If you absolutely cannot update immediately, you can mitigate the risk by disabling the admission controller webhook. This is done by setting the Helm chart value controller.admissionWebhooks.enabled=false or removing the --enable-admission-webhooks=true flag from the controller\u0026rsquo;s deployment arguments.\nWarning: Disabling the webhook removes validation safeguards and is not recommended as a long-term solution. Upgrade as soon as possible. Five Lessons for the Future This vulnerability serves as a stark reminder that even widely used components can harbor critical flaws. Prepare for future vulnerabilities, including zero-days, by adopting robust security practices:\nRestrict Egress Traffic: Limit outbound network connections from your cluster pods using Network Policies and external firewalls. This makes it harder (though not impossible) for attackers to download malicious tools (like kubectl) or exfiltrate data after gaining initial access. Minimize User Access (Embrace GitOps): Avoid giving users direct kubectl apply access to the cluster. Use GitOps workflows where changes are proposed via Git pull requests, reviewed (manually and potentially automatically with AI tools), and then automatically applied by a trusted agent (like Argo CD or Flux). Eliminate Shells in Containers: Do you really need a shell (/bin/sh, /bin/bash) inside your production containers? Often, you don\u0026rsquo;t. Remove shell binaries from your container images to significantly reduce the attack surface if an attacker gains execution within a container. For debugging, leverage Kubernetes\u0026rsquo; ephemeral containers feature. Use Trusted Images and Admission Control: Restrict the container registries allowed within your cluster. Use tools like Kyverno, Gatekeeper or builtin ValidatingAdmissionPolicy to enforce policies that only permit images from approved sources and potentially scan images for known vulnerabilities before deployment. Manage Your Platform with Code (IaC/GitOps): When infrastructure and platform components (like ingress-nginx) are managed declaratively via code (Terraform, Helm charts in Git, etc.), applying updates and patches across environments becomes significantly faster and more reliable. Fixing this vulnerability could be reduced to updating a version number in a Git repository and letting the GitOps process handle the rollout. Conclusion The ingress-nginx vulnerability is a serious threat due to its high CVSS score, widespread deployment, and the potential for complete cluster compromise via secret theft.\nWhile exploitation requires pre-existing cluster access, the potential impact necessitates immediate action. Updating the controller is the definitive fix. Furthermore, this incident underscores the critical need for layered security, least privilege principles (via GitOps), and managing infrastructure as code to respond effectively to future security challenges.\nIf you need help in fixing and secduring your cluster, I offer free consulting to companies that want to check, fix and secure their Kubernetes clusters.\n👉 See here for more info.\n","tags":["ingress","nginx","security","devsecops","kubernetes"],"title":"How critical is the ingress-nginx vulnerability?"},{"categories":["blog"],"date":"March 25, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/is-jenkins-dead/","section":"blog","summary":"Some may wish Jenkins disappeared completely. Apparently, it is still used in many companies. It can still be helpful, as long as it is properly managed.\nThere are 5 rules to make it more flexible, reliable and efficient:\n1️⃣ Run it inside container, preferably on Kubernetes\n2️⃣ Update plugins ONLY by rebuilding and testing a new image\n3️⃣ Use multiple instances by sharding it - assign it by team/department/environment etc.\n4️⃣ Use dynamically created pods as workers (use Kubernetes plugin)\n5️⃣ Manage jobs, configuration, access with code only - leverage JCasC (Jenkins Configuration as Code)\nI wish more companies would use Jenkins according to these rules. I’ve seen (and helped) many where it’s a reliable and mature cornerstone of the delivery platform.\n🤔 And what do you think? Will Jenkins be finally replaced by other, newer solutions? If so, which one is your favourite?\n","tags":["kubernetes","jenkins","cicd","devops"],"title":"Is Jenkins Dead?"},{"categories":null,"date":"March 24, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/solutions/kubernetes-deployment-factory/","section":"solutions","summary":"\nOverview This solution provides a comprehensive, secure, and automated approach to managing containerized applications. By integrating Gitlab CI for continuous integration, Argo CD for continuous delivery, and leveraging the scalability and resilience of Kubernetes, it empowers development, platform, and management teams to deliver value faster and more reliably.\nThe GitOps-centric design ensures that infrastructure and application configurations are managed as code, promoting auditability, version control, and automated reconciliation.\nFeatures This solution is packed with features that streamline the development and deployment process.\nEasy building \u0026amp; testing is achieved through optimized CI pipelines, simplifying the creation and validation of containerized applications. These robust pipelines help to ensure code quality and reduce the risk of errors.\nFurther enhancing efficiency, the solution allows super fast deployments via Argo CD, which automates the deployment process to Kubernetes.\nThese deployments, driven by delivery via GitOps, manage infrastructure and application configurations as code in Git, delivering auditability, version control, and automated reconciliation.\nThe solution is also compatible with any containerized software, working seamlessly with applications packaged as Docker containers and orchestrated by Kubernetes. Moreover, it provides dynamically created on-demand/preview environments, temporary spaces useful for showcasing and testing features before merging to production.\nIn addition, the platform is properly secured with the \u0026ldquo;restricted\u0026rdquo; Pod Security Standard to enforce strict security policies and protect applications and infrastructure. Finally, you can generate SBOM for all artifacts, ensuring transparency and aiding in vulnerability management.\nBenefits The solution yields significant benefits across development, platform, and management teams, driving efficiency, security, and innovation.\nFor Development Teams This solution significantly empowers development teams with a focus on streamlined processes and reduced complexities.\nUnified deliveries are made possible through standardized Gitlab CI templates, unified Dockerfiles, and application profiles, ensuring consistency across projects.\nUnified change management simplifies the process of modifying both the platform and applications, as changes are delivered through the same automated pipelines.\nDevelopment cycles become shorter, leading to reduced TTM (Time to Market), as the elimination of manual steps and long wait times allows for faster feature releases.\nFaster onboarding of new projects is also possible, as the ready-made and automated infrastructure enables developers to focus on delivering value rather than dealing with setup and configuration.\nIn addition, build platforms exhibit excellent scalability, growing to meet changing demands.\nFinally, more efficient testing is possible through dynamic preview environments.\nFor Platform Teams Platform teams experience a significant reduction in operational overhead and improved control.\nUnified change management translates to less chaos and promotes best practices across the organization, simplifying platform management. This in turn leads to reduced errors, fewer \u0026ldquo;fires,\u0026rdquo; less stress, greater stability, and fewer calls during on-call duty.\nPlatform teams will also benefit from better control over changes / increased transparency, thanks to the ability to easily track any change through GitOps.\nHigh availability is achieved via the GitLab architecture which provides a continuously available build platform.\nFinally, including an SBOM makes it easier to track down all the software components for security compliance.\nFor Management For management, the benefits translate to strategic advantages and cost savings.\nA faster development cycle results in reduced TTM (Time to Market), fostering faster innovation and a competitive edge. Projects are onboarded much faster due to pre-configured environments, allowing teams to focus on delivering value, not on maintenance.\nManagement can rely on high availability of the build platform, a crucial capability for organizations to deploy software fast and reliably.\nThey can also count on increased security because SBOM is included in the solution, which is designed with security in mind.\nFinally, this solution is cost-effective thanks to being highly scalable and reducing waste that is common with implementing dedicated solutions.\nIngredients This solution relies on several essential components working in concert.\nA Gitlab CI instance, running on Kubernetes, forms the foundation for continuous integration. This instance is created and maintained with code via GitOps, ensuring that its configuration is version controlled and reproducible.\nArgo CD, with separate dev and prod instances installed on Kubernetes clusters, handles continuous delivery.\nKubernetes itself is a critical ingredient, requiring at least two clusters – one for development and one for production. An optional dedicated cluster can further isolate the build environment, hosting the Gitlab CI instance, Gitlab runners, and Docker executors.\nFinally, the organization of Git repositories is critical to effective operation. The solution uses the following repositories:\nApplications: To store the source code for individual applications. CI: To store CI templates and custom CI configurations. CD: To store deployment manifests and configurations. Management: To store infrastructure and platform configurations. Description There are three major areas of the solution. Each has its own purpose and is built using the ingredients mentioned previously.\nContinuous Integration (CI) Individual application code resides in their respective application repositories.\nA dedicated CI repository stores reusable CI templates and custom CI configurations, including GitLab CI templates and a custom container image for docker executor with custom tools (e.g. Kustomize, Skaffold, Buildpacks, curl, etc.).\nGitlab CI is triggered by commits to an app repo and runs within the GitLab CI instance. The Gitlab CI instance uses a custom docker image and the builtin registry.\nThe pipeline uses templates from ci and runs on a container created from the custom image. The pipeline uses the API for GitLab to push, pull, check status, create merge requests, and create comments. This builds, tests, generates image and publishes it.\nFinally, the template ends by generating manifests and publishing them to CD repository. These can be:\nStatic manifests Modified Kustomize overlays Helm Chart values Continuous Deployment (CD) Deployment is centered around the CD repository, which houses deployment manifests and configurations. This repository acts as the single source of truth for the desired state of your applications.\nThe CI pipeline ensures that the CD repo always reflects the latest successful build by performing automated pushes after a successful build and test cycle. These automated pushes trigger the creation of a MR created by CI templates. This merge request contains the proposed changes to the deployment manifests and configurations.\nTo ensure that changes are properly reviewed and validated, the merge request is subject to code reviews and automated checks by authorized team members.\nThese automated checks can include linting, security scanning, and integration tests to ensure the changes meet the required quality and security standards.\nAfter the checks pass, the changes undergo an approval -\u0026gt; merge process, managed by authorized teams. This multi-stage approval process ensures that only validated and authorized changes are deployed to the environment.\nFor each environment (development, pre-production, and production), a specific Argo CD instance is deployed, such as the Argo CD dev instance. This instance is responsible for monitoring the CD repo and synchronizing the environment to match the desired state defined in the manifests.\nIt has the following characteristics:\nRuns in Kubernetes dev cluster: The Argo CD dev instance is deployed and runs within the development Kubernetes cluster, providing a dedicated deployment management environment for the development team. Managed with code from the management repository: The configuration and management of the Argo CD instance itself are managed as code within the management repository, ensuring consistent and reproducible deployments. Restricted access based on roles: To maintain security and prevent unauthorized changes, access to the Argo CD instance is restricted using role-based access control (RBAC), with most users granted read-only access. This ensures that only authorized personnel can make changes to the deployment configurations. Changes managed using resources defined in code: Argo CD applies changes based on Application resources, which define the desired state of the application. Points to a path in the cd repository: Application resources point to a specific path in the CD repo containing the deployment manifests. Can create namespaces for on-demand environments: Argo CD can create namespaces dynamically for on-demand/preview environments if required for a complex testing scenario. Platform Management The management repository serves as the central control plane for the entire platform, encompassing infrastructure configuration, shared service deployments, and security policies.\nThe core principle behind this repository is to manage \u0026ldquo;Everything as Code\u0026rdquo;, enabling GitOps-driven operations for consistent, auditable, and reproducible platform management.\nThe entire platform is managed as code and deployed using GitOps principles, enabling automated reconciliation and drift detection. The management repository contains the complete configuration for all Kubernetes resources required for the platform, including:\nQuotas: Resource quotas for limiting resource consumption by applications. Secrets: Secure storage of sensitive information, such as passwords and API keys. Netpol: Network policies for controlling network traffic between applications and services. RBAC: Role-based access control for managing user and application permissions. GitLab instance configuration: Configuration files for managing and configuring the GitLab instance Shared services configuration: Definition and configuration of shared services, for example such as: Databases: Configuration for deploying and managing shared database instances. Kafka: Configuration for deploying and managing shared Kafka clusters. Critical components: Management and configuration of critical infrastructure components. Backups, upgrades, tuning, troubleshooting: Procedures described in code and configurations for backing up, upgrading, tuning, and troubleshooting shared services. The management repository is managed by the dedicated platform team, responsible for maintaining the stability, security, and performance of the platform.\nThe structure of the management repository can be organized as a single repository or multiple repositories in a hierarchical layout, depending on the complexity and organizational structure.\nSimilar to the development instance, an Argo CD prod instance exists, responsible for deploying and managing applications in the production environment. This instance adheres to the same principles as the development instance but with stricter security and access controls:\nEven more restricted access: The production Argo CD instance operates similarly to the development instance, but with enhanced security measures and stricter access control policies to safeguard the production environment. Runs in Kubernetes production cluster: The Argo CD instance operates in the production Kubernetes cluster to manage its configuration and the deployment of the applications. Managed with code: Like the development instance, it\u0026rsquo;s managed as code from the management repository. Use Scenarios Several key use cases benefit from this approach, highlighting the advantages of automation, security, and agility it provides.\n1. Rollback flawed version of an app Imagine a scenario where a new version of your application has just been deployed to production, but shortly after deployment, critical bugs are discovered, impacting users. Time is of the essence to minimize the damage. The solution facilitates a swift rollback by leveraging the CD repo.\nFirst, you check for commit information to identify the specific commit associated with the problematic deployment, either by inspecting Argo CD\u0026rsquo;s UI, examining pod labels, or reviewing the CD repo details. Knowing the faulty commit hash is crucial for identifying the problematic changes.\nNext, you find the MR and revert changes in the CD repository, effectively undoing the problematic deployment configuration. This is typically achieved by creating a new merge request that reverts the changes introduced in the previous deployment.\nFinally, you wait for Argo CD to sync, which automatically applies the older, stable state of the application to the production environment. Argo CD constantly monitors the CD repository, and upon detecting the reverted changes, it automatically reconciles the production environment to match the previous, stable configuration.\nThis process allows for a rapid return to a functioning state, minimizing disruption and preserving user experience. The entire rollback process is automated, auditable, and repeatable, significantly reducing the manual effort and risk associated with traditional rollback procedures.\n2. Implement \u0026ldquo;Quick Fix\u0026rdquo; for an app When a critical bug or security vulnerability is identified in your application, a rapid response is essential to mitigate potential risks.\nIn cases where a rollback isn\u0026rsquo;t feasible or has already failed, perhaps due to data migrations or incompatible changes, this solution allows you to implement a quick fix and get it into production swiftly.\nThe process begins with developing the solution, making the necessary code changes to address the issue. This might involve bug fixes, security patches, or configuration adjustments.\nNext, you push to the git repo, triggering the automated CI process. The build is triggered, running tests to validate the fix, and a container image is built and published to the container registry.\nComprehensive testing is performed to ensure the fix resolves the issue without introducing new problems.\nAfter this, a new kustomize overlay is created with a new image, configmap, and other necessary changes to incorporate the fix. This overlay allows the platform teams to change certain parts of the application config (like the image version), without having to overwrite the whole configuration.\nThis new overlay is pushed to a repo in a new branch, creating new merge requests for development, pre-production, and production environments. This makes sure, that changes are only applied if other team members approve of the changes.\nThe CI finishes its process, and auto checks are performed on the newly created MR.\nThese automated checks can include linting, security scanning, and integration tests to ensure the changes meet the required quality and security standards.\nOnce the auto-checks pass, someone with the proper role accepts the MR and merges changes to the main branch. Upon merging, Argo CD automatically syncs changes on the dev cluster.\nThis allows developers to quickly check the changes and see, if their changes work. After initial validations on the dev cluster, you perform some additional tests.\nThe same sequence is repeated for pre-production - by merging the same changes, then let ArgoCD sync. This allows for testing the changes in a staging like environment. Lastly, because of the importance of the change the approval step on prod is manual. An operator carefully checks the changes and approves the MR. Argo CD syncs changes on the prod cluster.\nAfter a few minutes from git commit new app is running on prod.\n3. Implement big change in a new version of app When introducing significant changes to your application, such as a major feature release, database schema migration, or architectural refactoring, thorough testing and validation are paramount to ensure stability and user satisfaction.\nThis solution enables you to leverage on-demand preview environments for comprehensive testing before deploying to production.\nThe process commences with developing changes and pushing to the app repo in a new branch. Creating a dedicated branch allows for isolating the new features and changes from the main development branch, preventing disruptions to existing functionalities.\nA container image is built and pushed to the registry, and Kubernetes resources are rendered and pushed to the CD repo. Creating dedicated images for new features allows teams to try out new versions without having to deploy them to production.\nAfter that, a new merge request is created. To leverage the new features, the developer initiates tests on a preview environment with a proper comment in the MR. A comment in the MR signals the CI pipeline to do something special, like deploying the created image to a preview environment.\nThe CI pipeline adjusts manifests to include the preview environment.\nThe Argo CD picks up manifests, creates a namespace for the preview environment, and deploys the app.\nAfter a few minutes, the app is ready for thorough testing on a brand new env. This environment offers isolated, realistic conditions for thorough testing and validation of the new features, ensuring a stable and high-quality release to production. Once testing is complete, preview env is destroyed when MR is closed or merged.\n4. Grant access to external service for an app Applications often require access to external services, such as databases, APIs, or message queues, to fulfill their functionality. Securely and reliably granting this access requires careful management of network policies, secrets, and service accounts.\nIn this scenario, a platform team member develops changes in manifests. These changes might include modifying network policies to allow traffic to the external service, providing secrets containing credentials for authentication, or assigning roles to the service account to grant appropriate permissions.\nFor example: If an application needs to connect to a database, the network policies must allow access to the database port and the secret must include the database password.\nAfter the changes are proposed, automatic checks are run to validate changes. These checks can include validating the syntax of the manifests, ensuring the network policies do not conflict with existing policies, and verifying the secrets are properly encrypted and stored.\nAfterwards, a code review and approval process starts. This process is initiated to make sure, that changes are only applied with the consent of other members of the platform team.\nFinally, the changes are merged to the main branch. Once merged, Argo CD picks up changes and applies them on the cluster either automatically or manually for critical areas.\n5. Implement new policy Organizations often face new requirements driven by evolving policies, regulations, or industry standards. Complying with these requirements can necessitate changes across multiple components of the CI pipeline and platform.\nThis scenario outlines the steps to implement such changes in a structured and controlled manner.\nFirst, introduce new ci templates for apps. Before enforcing a new change it is important to create new solutions and get some feedback.\nThen ask a few teams to start using it - open a feedback loop and collect their feedback.\nFixes are applied, and after that, the improved template can be published as the new version of the CI template. That triggers a new announcement of the version to encourage teams to migrate and give a grace period for the new changes. Before the final enforcement, teams must be made aware of what is coming.\nFinally, the old versions must be deprecated by forcing the teams to upgrade and provide help during migrations.\nDuring all those steps, the platform teams must introduce new changes, validate and revert if needed. These can include setting webhooks, Kyverno policies or other custom resources.\nImplementation This solution offers a flexible and efficient implementation path, designed to integrate seamlessly with your organization\u0026rsquo;s existing tools and processes while adhering to industry best practices for security and automation.\nDuration The initial setup of this solution can be remarkably fast.\nIn as little as two weeks, a fully functional environment can be established, complete with the ability to deploy and manage your first application.\nThis rapid deployment time ensures a quick return on investment and allows your development teams to start leveraging the benefits of the solution immediately.\nMethod Everything within the solution is managed as code, employing GitOps principles for consistent and automated configuration management.\nThis is facilitated through the use of operators, such as the GitLab operator and Argo CD operator, which automate the deployment and management of these critical components within your Kubernetes environment.\nConfigurations are developed throughout the implementation process to align precisely with your organization\u0026rsquo;s specific context, needs, and existing workflows. This includes customizing several key aspects:\nCI Pipeline Templates: The implementation tailors CI pipeline templates to your specific needs and standards to fit existing tools and business processes. These templates encapsulate your organization\u0026rsquo;s preferred build, test, and deployment processes, ensuring consistency and compliance across all applications. Application Profiles: The creation of application profiles allows teams to group CI processes (build, test) by technology or framework. Each profile also includes deployment source information specifying whether deployments are managed via helm chart or kustomize with overlays. Security Controls: Robust security controls are established during implementation, with a strong emphasis on access control. Access Control to Git: Secure and controlled access to Git repositories is essential for maintaining the integrity and confidentiality of your code. This access control acts as a single point of truth and control, preventing unauthorized modifications and ensuring compliance with security policies. Access Control to Argo CD: Similarly, strict access control to Argo CD is implemented to restrict access to deployment configurations and prevent unauthorized deployments. This measure safeguards your environments from malicious or accidental changes. Requirements To effectively utilize this solution, several requirements must be met:\nThe applications must already be containerized, indicating that they should be packaged as Docker containers for seamless integration with the system.\nAn optional existing SSO solution can be integrated to manage user authentication. If no SSO solution exists, Gitlab accounts can be used for access to both Git and Argo CD.\nA working Kubernetes environment is required. This environment can be hosted on a cloud platform (e.g., EKS, AKS, GKE) or deployed on-premise, provided it has DNS configured for services and access to Let\u0026rsquo;s Encrypt or another mechanism for providing trusted TLS certificates.\nA reliable storage solution for Git repositories, the container registry, and the build cache, with additional object storage (e.g., S3) recommended for storing backups.\n","tags":["gitlab-ci","cicd","gitops","argocd","kubernetes","platform-engineering"],"title":"Kubernetes Deployment Factory"},{"categories":["blog"],"date":"March 24, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/azureday-poland-2025/","section":"blog","summary":"Did you know that your AKS cluster could be vulnerable? Even with RBAC and continuous updates?\nKubernetes is universal and can support any type of application. However, this comes at a price. There are options that open the door for attackers and can make your environment vulnerable. In this presentation, I will show the importance of protecting pods with a built-in solution - Pod Security Admission.\nThe presentation includes a LIVE DEMO of an attack using really simple techniques and tools.\nCome to my presentation at AzureDay Poland 2025 to find out!\n👉 Use this special promo code to get 15% off your ticket: AzureDay2025Speaker\nTickets and details available on the event site: https://azureday.pl/\nUPDATE: 24 March 2025 Here\u0026rsquo;s the link to the resources I used during the demo: https://github.com/cloudowski/hacking-kubernetes\n","tags":["conferences","azure","kubernetes","security"],"title":"See you at AzureDay Poland 2025"},{"categories":["blog"],"date":"March 20, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/its-not-real-gitops-if/","section":"blog","summary":"No, you don\u0026rsquo;t really have GitOps if your applications are deployed from imperative CI/CD pipelines. GitOps is more than just using Git.\nIt\u0026rsquo;s about making Git the single source of truth for your entire system\u0026rsquo;s desired state. If your deployments still rely on manually triggered pipelines or scripts outside of Git, you\u0026rsquo;re missing the core benefits. It\u0026rsquo;s just a fancy CI/CD.\nWith true GitOps, any change to the application is done via pull request to Git - application deployment is triggered automatically.\nGitOps benefits? Increased auditability, simplified rollbacks, improved collaboration, and faster deployments. Everything is traceable and can be reverted to previous states in moments.\nIs it easy to adopt full GitOps? No. It requires a shift in mindset and tooling. Is it worth it? Absolutely YES! The increased reliability and speed of delivery are invaluable 💪.\nIs Git truly the single source of truth for your infrastructure and applications? If your deployment is automatic - great - but is it auditable?\n","tags":["kubernetes","gitops","devops"],"title":"It's not REAL GitOps"},{"categories":["blog"],"date":"March 18, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/kubernetes-without-autoscaling-is-wasteful/","section":"blog","summary":"Using Kubernetes without proper autoscaling is like a Ferrari stuck in first gear. You\u0026rsquo;re wasting enormous potential for cost savings, responsiveness, and resource utilization. Autoscaling is very important to use Kubernetes platform efficiently.\nWith Kubernetes running in the cloud, the money savings are obvious – you pay less for computing services. By scaling down during off-peak hours, and spinning up new instances to handle increases in traffic you will optimize the platform based on actual utilization.\nFor on-prem platforms, you can still utilize the hardware better and even reduce power consumption by turning off unused nodes. Proper autoscaling helps to keep your environment green and environmentally responsible.\nThere are multiple types of autoscaling:\n1️⃣ Vertical Pod Autoscaler (VPA) - for CPU and memory\n2️⃣ Horizontal Pod Autoscaler (HPA) - to adjust number of pod instances\n3️⃣ Cluster Autoscaler (CA) - to scale out/in entire cluster\nNot configuring autoscaling is a waste. It’s all about being green – either 💶 or 🌿!\n","tags":["kubernetes","autoscaling"],"title":"Kubernetes without autoscaling is just wasteful"},{"categories":["newsletter"],"date":"March 18, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/128/","section":"newsletter-archive","summary":"Tu nie chodzi tylko o uczenie się. W kontekście naszego rozwoju ogromnie znaczenia ma też dopasowanie do własnych predyspozycji i upodobań.\nDlaczego o tym piszę? Bo właśnie podjąłem pewną ważną decyzję na tej podstawie.\nOdkrywając AI odkryłem co lubię najbardziej Postanowiłem, że nie będę już więcej tworzył wideo o AI. Prawdopodobnie nie będę tego też tematu drążył głębiej. Odkryłem, że wolę być świadomym użytkownikiem ułatwiającym sobie pracę z pomocą narzędzi AI.\nPowodów jest kilka. Teraz jest boom i mnóstwo osób oferuje już treści edukacyjne z tego obszaru. Dodatkowo tempo zmian jest olbrzymie i treści takie będą szybko się dezaktualizować.\nAle to co innego pomogło mi podjąć tę decyzję.\nTo nie dla mnie. Owszem, jest to ciekawe, interesujące, ale nie czułem tego. Tak - po prostu nie miałem tego poziomu ekscytacji jak w przypadku innych obszarów, którymi do tej pory się zajmowałem. Okazuje się, że gdy uczę się nowych technologii z obszaru DevOps i Platform Engineeringu to wpadam często w stan tzw. flow. To bardzo przyjemne i motywujące uczucie, którego mi brakowało przy nauce AI.\nNie wiem dlaczego tak jest, ale wiem, że bez tego jest ciężej.\nWybieramy zawód często przez przypadek, ale też często podświadomie czujemy, że coś nam bardziej pasuje a coś mniej. Ja kolejny raz zawęziłem mój obszar i nauczyłem się czegoś o sobie.\nWedług mnie w naszej branży (DevOps/Platform Engineering) jest wiele osób, które lubią to z tych samych powodów co ja i dlatego nie wybrały innej. I to jest ok. Lepiej jest budować karierę na silnych stronach, cechach które dostaliśmy w loterii genetycznej i jednocześnie na czym co sprawia satysfakcję.\nZatem jeśli podobnie jak ja czujesz, że \u0026ldquo;powinieneś\u0026rdquo; pójść w jakiś obszar, bo to jest modne/bardziej dochodowe/przyszłościowe, a z jakiegoś powodu cię tam nie ciągnie, to odpuść sobie. Skup się na tym co daje ci satysfakcję i gdzie możesz wykorzystać swoje silne strony.\nNaucz się wykorzystywać AI, aby jeszcze lepiej użyć swojej gromadzonej przez lata wiedzy i doświadczenia.\n💡 Im większa twoja wiedza ekspercka tym większe korzyści przyniesie ci AI.\nWszystkie części serii “AI w minutę” Oto pełna lista 20 filmów. Przygotowanie ich pomogło mi poznać AI (a głównie LLM) od środka i zrozumieć możliwości oraz ograniczenia.\nMam nadzieję, że pomoże też innym.\n1: Jaka jest różnica między AI a LLM?\n2: Czym jest LLM?\n3: Jak powstaje LLM?\n4: Jaka działa LLM?\n5: Czym są parametry w LLM?\n6: Ile kosztuje korzystanie z LLM?\n7: Czym jest self-attention?\n8: Czym jest cutoff w LLM?\n9: Czym są tokeny?\n10: Czym są embeddings?\n11: Czym jest RAG?\n12: Czym jest prompt engineering?\n13: Jak uczyć AI z własnych danych?\n14: Dlaczego LLMy halucynują?\n15: Czym jest fine-tuning modelu? 16: Czy korzystanie z LLM jest bezpieczne?\n17: Do czego potrzeba matematyki w LLM? 18: Czym są agenty AI?\n19: Co potrafią agenty AI?\n20: Czym się różni workflow od agenta AI?\n","tags":["newsletter","ai","rozwojosobisty"],"title":"Newsletter #128 - Koniec iteracji"},{"categories":["blog"],"date":"March 14, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/blog/is-kubernetes-insecure/","section":"blog","summary":"⚠️ Did you know your Kubernetes can be insecure? If you don’t use Kyverno, Open Policy Agent then here’s what single setting must be present on your Kubernetes.\nMake sure your namespaces have a “baseline” or “restricted” (highly recommended!) pod security profile set with the following annotation (this may cause applications to not be able to start):\npod-security.kubernetes.io/enforce: baseline I have demonstrated many times the real risks of running containers without this setting, and it’s terrifying how easy it is to steal data with even limited access to Kubernetes API.\nIf your environment has no pod security profile and you don’t use any other admission control (.e.g. Kyverno, OPA) then don’t hesitate to contact me. I will demonstrate to you the risks of not having these safeguards in place and help you secure and adjust your environment to the pod security profiles.\n","tags":["kubernetes","security"],"title":"Is Kubernetes Insecure?"},{"categories":["articles"],"date":"March 10, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/from-cicd-to-ci-and-cd-a-modern-deployment-with-gitops/","section":"articles","summary":"Continuous Integration and Continuous Delivery (CI/CD) has become an indispensable cornerstone of modern software development, enabling teams to automate the build, test, and deployment processes. However, the traditional CI/CD pipeline, where a single system orchestrates both building and deploying, can become a bottleneck, especially in complex, cloud-native environments. This article examines the limitations of this monolithic approach and introduces a more robust and scalable alternative: separating the CI process from the CD process and leveraging GitOps principles. We\u0026rsquo;ll delve into the benefits of this evolved strategy, including improved resource utilization, enhanced rollback capabilities, a declarative approach that aligns with modern infrastructure, and enhanced security.\nLimitations of Traditional CI/CD In the early days of CI/CD, infrastructure management was often treated as a separate concern, handled through configuration management tools like Ansible, Puppet, Chef, or even ad-hoc scripts. Changes were frequently applied on demand, leading to configuration drift, inconsistencies across environments, and the ever-present need for hotfixes to address unexpected issues. Even with the adoption of DevOps practices and cross-functional teams, a clear separation between development and operations often persisted, creating communication silos and hindering agility.\nThe CI/CD pipeline itself, often a single monolithic entity responsible for both building and deploying, became a central point of complexity, incorporating custom logic and following an imperative approach. While the CI stage typically handled testing, building artifacts, and creating container images, the CD stage often involved automated deployments to non-production environments followed by manual approvals for production deployments. This hybrid approach, while offering some improvements over manual processes, ultimately falls short in addressing the challenges of modern, cloud-native architectures.\nThe classical CI/CD pipeline approach, which tightly couples building and deploying into one automated flow, exhibits several critical shortcomings that limit scalability, reliability, and security:\nDifficult and Often Incomplete Rollbacks: Traditional CD pipelines often construct deployment manifests \u0026ldquo;on the fly\u0026rdquo; using scripts or templating engines, and immediately deploy them to clusters. This makes rollbacks complex and incomplete, as there\u0026rsquo;s no complete audit trail of the precise deployment process. Often, the manifests themselves are not versioned, making true rollback impossible without significant manual intervention and a deep understanding of the system\u0026rsquo;s history. Tight Coupling and Reduced Flexibility: The tight coupling between building and deploying reduces flexibility and increases complexity. Changes to the deployment process (e.g., adding a new deployment strategy, modifying resource limits) often require modifications to the CI pipeline, and vice versa. This interdependency increases the risk of unintended consequences and hinders the ability to iterate quickly on both the application and the deployment process. The Imperative vs. Declarative Conflict: Employing an imperative approach to manage declarative systems like Kubernetes (or other Infrastructure-as-Code tools like Terraform/OpenTofu) is inherently problematic. Why manage a system whose core philosophy is based on desired state with sequences of commands? This leads to inconsistencies, difficulties in tracking changes, and increased complexity in troubleshooting issues. Deployment Disconnect and Lack of Unified Management: Deployments are often treated as separate events, disconnected from platform changes. However, in reality, the platform exists to serve the application, and changes in one often necessitate changes in the other. Consider explicit versioning of platform components alongside application code. A unified approach to managing both application deployments and platform changes – ideally through GitOps – greatly simplifies operations, diagnostics, and rollbacks, providing a holistic view of the system\u0026rsquo;s state. Limited Auditability and Security Risks: Traditional CI/CD pipelines often lack robust audit trails, making it difficult to track who made what changes and when. This can create security vulnerabilities, especially if sensitive credentials or configuration parameters are embedded directly within the pipeline scripts. Without a clear audit trail, it becomes challenging to detect and respond to malicious activity or unauthorized changes. Resource Contention and Scalability Issues: A monolithic CI/CD pipeline can become a resource bottleneck, especially when handling multiple concurrent builds and deployments. This can lead to increased build times, delayed deployments, and overall reduced agility. Furthermore, scaling the pipeline to handle increased workload often requires significant investment in infrastructure and operational overhead. Embracing Separation and GitOps: A New Paradigm for CI/CD To overcome the limitations of traditional CI/CD, we can decouple the build and deployment processes, creating a more scalable, resilient, and secure system. This involves embracing GitOps principles to manage the deployment process in a declarative and auditable manner.\nHere\u0026rsquo;s a breakdown of this evolved approach:\nDedicated CI for Building and Artifact Creation: Leverage your existing CI engine (e.g., Jenkins, GitHub Actions, GitLab CI) to focus solely on building, testing, and creating artifacts. This includes compiling code, running unit tests, performing integration tests, building container images, generating deployment manifests, and creating release packages. The CI process should produce well-defined, immutable artifacts that are ready to be deployed. GitOps-Powered CD for Declarative Deployment Management: This is where the real transformation occurs. Define the desired state of your applications declaratively in a Git repository (or a set of repositories). This repository becomes the single source of truth for your application deployments, specifying the desired version of each application, the target environment, the resource limits, the configuration parameters, and any other relevant deployment settings. The GitOps Engine: Automating Synchronization and Enforcement: Employ a GitOps engine (e.g., Argo CD, Flux CD) to automatically synchronize the desired state defined in the Git repository with the actual state of your environment. The GitOps engine continuously monitors the Git repository for changes and automatically applies those changes to your environment, ensuring that the actual state always matches the desired state. Unified Management and Holistic Visibility: Integrate the management of application deployments with platform changes. Because some platform changes depend on application changes (e.g., through explicit versioning of platform components, shared libraries, or API contracts), managing them together simplifies operations, diagnostics, and rollbacks, providing a holistic view of the system\u0026rsquo;s state. This unified management approach reduces the risk of inconsistencies and ensures that changes are applied in a coordinated and predictable manner. Who Stands to Benefit the Most? Identifying the Ideal Candidates While the benefits of this separated CI/CD and GitOps approach are significant for many organizations, the magnitude of these benefits tends to correlate with the complexity and scale of their operations.\nLarge, Complex Organizations: The biggest gains will be realized by large organizations with numerous complex projects, multiple teams and departments, and dozens (if not hundreds) of applications. The increased control, auditability, and consistency that GitOps provides are invaluable when managing deployments at scale. These features help to streamline operations, reduce the risk of errors, and improve overall security. Startups with Greenfield Projects: This approach is also highly beneficial for startups with greenfield projects. By adopting a GitOps-based deployment strategy from the outset, they can establish a scalable and reliable deployment process from the ground up. This helps them to reduce technical debt, accelerate innovation, and grow faster. Quantifiable Benefits of the New Approach Adopting a separated CI/CD approach with GitOps delivers a wide range of tangible benefits:\nAccelerated Time to Market: Faster release cycles and reduced Time To Market (TTM) are crucial for maintaining a competitive edge. By automating the deployment process and eliminating manual steps, GitOps enables teams to deliver new features and bug fixes more quickly and efficiently. Enhanced Transparency and Auditability: Every change is tracked in Git, providing a clear and comprehensive audit trail of all deployments. This improved visibility makes it easier to track down problems, identify security vulnerabilities, and comply with regulatory requirements. Simplified and Complete Rollbacks: Reverting to a previous state is as simple as reverting the corresponding commit in the Git repository and allowing the GitOps engine to automatically synchronize the changes. This eliminates the complexity and risk associated with manual rollbacks, ensuring that the system can be quickly and reliably restored to a known good state. Everything as Code and Infrastructure as Code: The GitOps approach fully supports the \u0026ldquo;Everything as Code\u0026rdquo; (EaC) philosophy, preventing the chaos and inconsistencies that traditional CI/CD pipelines can introduce. By treating infrastructure, configurations, and deployment manifests as code, teams can automate and standardize the entire deployment process, ensuring consistency and repeatability across environments. Improved Security and Compliance: By managing all deployment configurations in Git, you gain improved control over access and permissions. Git\u0026rsquo;s built-in version control and audit logging provide a strong foundation for security and compliance. Furthermore, by integrating security checks into the CI pipeline, you can identify and address potential vulnerabilities before they reach production. Enhanced Collaboration and Reduced Errors: The declarative nature of GitOps promotes collaboration and reduces the risk of human error. By expressing the desired state of the system in code, developers and operations teams can work together more effectively to define and enforce consistent deployment policies. Scalability and Resiliency: By decoupling the CI and CD processes, you can scale each component independently to meet changing demands. This ensures that your deployment pipeline remains responsive and resilient, even under heavy load. Practical Steps for Adopting CI \u0026amp; GitOps Implementing CI \u0026amp; GitOps may seem daunting at first, but the process is surprisingly straightforward when broken down into manageable steps:\nSelect a Git Provider: Choose a Git provider (e.g., GitHub, GitLab, Bitbucket) that meets your security and collaboration needs. Establish a clear repository structure, including a dedicated \u0026ldquo;source of truth\u0026rdquo; repository (or set of repositories) for GitOps-managed deployments. Carefully consider repository access control to limit who can modify the infrastructure. Configure Your CI Pipeline: Modify your existing CI engine (e.g., Jenkins, GitHub Actions, GitLab CI) to focus on building container images, running tests, and generating deployment manifests. The CI pipeline should not directly deploy anything to your environment. Instead, it should commit the generated manifests to the GitOps repository. Ideally, the CI pipeline should not only create commits but also create new branches and automatically generate pull requests for those changes. Integrate a GitOps Engine: Choose a GitOps engine that aligns with your needs and connect it to your GitOps repository. Argo CD is a popular and powerful solution for many use cases, offering a wide range of features and integrations. Flux CD is a lightweight alternative that is well-suited for smaller environments or when you need a more streamlined solution. Configure the GitOps engine to automatically synchronize the desired state defined in the Git repository with your environment. Define Deployment Policies: Establish clear deployment policies and procedures that are enforced through the GitOps engine. This includes defining deployment strategies (e.g., rolling updates, blue/green deployments, canary releases), resource limits, security policies, and monitoring thresholds. These policies should be expressed as code and versioned in Git. Automate Validation and Testing: Integrate automated validation and testing into your CI/CD pipeline to ensure that changes are thoroughly tested before they are deployed to production. This includes running unit tests, integration tests, end-to-end tests, and security scans. You can also use tools like Open Policy Agent (OPA) to enforce custom policies and prevent deployments that violate those policies. Monitor and Observe Your System: Implement robust monitoring and observability practices to gain insights into the performance and health of your applications. Use tools like Prometheus, Grafana, and OpenTelemetry to collect and analyze metrics, logs, and traces. Set up alerts to notify you of any issues that require attention. Is GitOps Implementation Effortless? While adopting this approach may present initial challenges, the long-term benefits – reduced operational overhead, increased reliability, faster TTM, and improved security – make the investment worthwhile. The initial investment includes selecting the right tools, adapting deployment processes, and training staff. Experienced teams, particularly those already familiar with Infrastructure as Code and declarative configuration management, will find the transition easier to manage. Ultimately, GitOps is essential for teams looking to avoid the constant frustration and inconsistency often associated with traditional environments.\nConclusion: Embracing the Future of CI/CD with Separation and GitOps By separating the CI and CD processes and embracing GitOps principles, organizations can overcome the limitations of traditional CI/CD and achieve a more scalable, reliable, and auditable deployment pipeline. This evolved approach aligns perfectly with the principles of Cloud Native development and enables teams to deliver software faster, more efficiently, and with greater confidence. It\u0026rsquo;s a journey worth undertaking, leading to a more robust, secure, and agile software delivery process.\n","tags":["platform-engineering","gitops","cicd","containers","deployment","devops","kubernetes"],"title":"From CI/CD to CI\u0026CD: A Modern Deployment Strategy with GitOps"},{"categories":["newsletter"],"date":"March 4, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/127/","section":"newsletter-archive","summary":"Czasem trzeba wyjść z domu, ludzi zobaczyć, nawet porozmawiać, a dla profesjonalistów z branży najlepszym takim miejscem są konferencje i mniejsze wydarzenia.\nTak się składa, że wkrótce zaczyna się sezon, w którym uczestniczę i ja. To doskonała okazja do zaktualizowania wiedzy i spotkania.\nNadchodzące konferencje i wydarzenia W tych konferencjach i wydarzeniach jestem osobiście jako organizator, prelegent lub ucestnik. To nie jedyne wydarzenia, ponieważ w tym roku postanowiłem częściej występować i jak tylko dostanę potwierdzenia z kolejnych to oczywiście też dam znać.\n🗓️ 9 października 2025 - KCD Warsaw To najważniejsze wydarzenie roku - oficjalna konferencja Kubernetes Community Days wspierana przez CNCF.\nBardzo się cieszę, że jestem współorganizatorem tego wyjątkowego wydarzenia.\nSzczegóły wkrótce, ale już ciężko pracujemy nad tym, aby było ono naprawdę ciekawe dla profesjonalistów z branży. Śledź nas na social media:\nLinkedIn Facebook Twitter/X Instagram 🗓️ 12 marca 2025 - Cloud Native Warsaw To lokalne wydarzenie, gdzie również je współorganizuję. Ponownie spotykamy się w siedzibie Paramount w Warszawie, aby posłuchać ciekawych prezentacji i porozmawiać przy pizzy.\n👉 Można się jeszcze zarejestrować tutaj.\n🗓️ 13 marca 2025 - AzureDay Poland 2025 Tak się składa, że dzień później występuję na AzureDay, gdzie opowiem o (nie)bezpieczeństwie AKS.\nBilety jeszcze można kupić, a z kodem AzureDay2025Speaker dostaniesz 15% zniżki.\n🗓️ 1-4 kwietnia 2025 - KubeCon EU London Ja się wybieram jako uczestnik i jeśli również tam będziesz to dawaj znać. Często bywa tak, że w Polsce ciężko się spotkać, ale setki czy tysiące kilometrów dalej jest to o dziwo łatwiejsze.\nNowa strona z dostępem do archiwum newsletterów Właśnie opublikowałem moją nową stronę, o której pisałem w poprzednim newsletterze.\nI teraz możliwe jest przeglądanie archiwum wysłanych przeze mnie newsletterów. Nowe będą publikowane tam z tygodniowym opóźnieniem.\nNowe części serii “AI w minutę” Tradycyjnie na końcu przedstawiam listę dostępnych wideo tłumaczących jak działa AI.\n1: Jaka jest różnica między AI a LLM?\n2: Czym jest LLM?\n3: Jak powstaje LLM?\n4: Jaka działa LLM?\n5: Czym są parametry w LLM?\n6: Ile kosztuje korzystanie z LLM?\n7: Czym jest self-attention?\n8: Czym jest cutoff w LLM?\n9: Czym są tokeny?\n10: Czym są embeddings?\n11: Czym jest RAG?\n12: Czym jest prompt engineering?\n13: Jak uczyć AI z własnych danych?\n14: Dlaczego LLMy halucynują?\n15: Czym jest fine-tuning modelu? 16: Czy korzystanie z LLM jest bezpieczne?\n17: Do czego potrzeba matematyki w LLM? 18: Czym są agenty AI? 19: Co potrafią agenty AI? (niepubliczne - obecnie dostępne tylko dla subskrybentów)\n20: Czym się różni workflow od agenta AI? (niepubliczne - obecnie dostępne tylko dla subskrybentów)\n","tags":["newsletter","konferencje"],"title":"Newsletter #127 - Widzimy się na tych konferencjach"},{"categories":["articles"],"date":"March 3, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/how-ai-helped-me-to-migrate-my-website/","section":"articles","summary":"In AI, I am interested in practical applications, and I have found a very specific one.\nI used it for something very important to me - migrating my website from WordPress to Hugo, and I am very pleased with how smoothly it went thanks to AI (mainly LLM).\nWhy I decided to migrate from WordPress A few years ago, I was persuaded to use WordPress, and I still feel the consequences of that decision. Why?\nHere are a few reasons why I would never do it again:\nYes, WordPress is very popular, but it is a tool from another era and for a different type of audience - mainly for non-technical people who need to click through their content. I have nothing against PHP, but the way WordPress relies on trillions of plugins is a nightmare. It reminds me of Jenkins, where an innocent update of one plugin crashes the whole thing. It\u0026rsquo;s similar here. A database to store content? Totally pointless. And the content mixed with formatting makes an even bigger mess. Besides, I prefer my website backup to be a single git repository. Simplicity wins. And there\u0026rsquo;s no way to hack the site through some SQL injection. How slow it is! The site itself can be fast (if you install the right plugins), but editing it is a misunderstanding. I had the Elementor plugin, and it\u0026rsquo;s a disaster - every edit loads a huge amount of data into the browser and constantly queries the PHP backend for minor changes. Nightmare! I needed something better, and I already had such a solution before. It was Jekyll, which generated my blog from code. Those were wonderful times, and I decided to fix my mistake and return to my roots.\nWhy I chose Hugo Hugo is a CMS written in Go in the style of Jamstack. It is based on templates from which static pages (HTML+JavaScript) are generated.\nIt is fast in generation and logically organized. I can finally apply my “Everything as Code” approach to my website as well!\nHugo is really powerful, but it\u0026rsquo;s not intuitive - at least not at the beginning.\nIt reminds me a bit of Kubernetes - it also scares at first, but later you appreciate how logical and simple it is.\nHaving everything in code means I can host it anywhere.\nI used to use GitLab Pages or GitHub Pages, and now I chose Cloudflare Pages (highly recommended!). Of course, due to the simplicity of static pages, these services are free. For me, this is just an addition, as I see greater benefits elsewhere.\nCode-driven website Since I have everything in code, I can manage and publish my content much more efficiently.\nHere are the main advantages:\nFirst of all, I version everything in git without any plugins. Git is the best for this. I have better control over my content templates - separately text in Markdown and separately form in the form of templates. For publication, I only need a text editor (even vim would do) and I don\u0026rsquo;t have to click through the process - publication is trivial and involves saving changes into the file and a simple git push, and after a while, I have safe, fast, clear content available as static pages. If I want to change the layout, add features (forms, more interactivity etc.), I can hire a helper who understands the site code perfectly. Yes, that helper is AI. Thanks to having the site in code, it is much easier for me to use AI. Not only did it greatly facilitate the migration, but I will also use it in the future to make improvements.\nFor such WordPress, probably every publisher of hundreds of plugins will offer you their own AI-based solution available for an additional few (dozens?) of dollars extra per month.\nI need one interface to use AI here - a text editor with access to a good LLM.\nPreparations for migration Before AI, there were a few things I needed before starting the migration.\nFirst, I needed a template for my site. There are free ones available, but I bought a chosen template that I liked. I\u0026rsquo;m no graphic designer, but there are plenty of templates for very reasonable money.\nThe template wasn\u0026rsquo;t perfect, but it had many things I could use as a good starting point.\nThen I used Canva to adjust the look of the site. The template already had marked graphic formats, and I just chose matching graphics, asked AI if they would fit, and placed them where needed in the Hugo structure.\nUsing AI for migration When it came time to migrate content, I created some of it from scratch because I didn\u0026rsquo;t like a few things and needed to tailor them to what I currently want to offer my audience.\nI migrated a large part automatically. I used the wp2hugo project, which helped a bit, but I still had to correct a lot.\nAnd here comes the part for AI. Having a template, partially migrated content, and elements of the site that didn\u0026rsquo;t quite fit, I needed to change a lot.\nI initially hired the free GitHub Copilot built into VS Code, which did a decent job. It helped me adjust layouts and even learn advanced things with Hugo.\nLater, however, I hired a better helper - Cursor. And I must say, I\u0026rsquo;m impressed.\nIt handled the tasks I gave it excellently. It found references throughout the code, made changes, and suggested improvements. It even found and fixed a bug in the original template!\nAdditionally, I chatted with Google\u0026rsquo;s model in the meantime. I used AI Studio to talk about the site layout, using Hugo features, choosing icons, and preparing a few scripts. One of them allowed me to quickly catch broken links (returning 404) and fix them in the code.\nAnd so I migrated in about a week from a slow, hack-prone, plugin-overloaded overwhelming WordPress to a lightweight, pleasant, secure solution on Hugo.\nSummary This is the kind of practical AI I value the most - specific benefits and specific savings.\nClickable interfaces may be nice for laypeople, but in the age of AI, code is much easier to use with AI. And \u0026ldquo;Everything as Code\u0026rdquo; for me also means creating content this way.\n","tags":["ai","everything-as-code","wordpress","hugo"],"title":"How AI helped me to migrate my website"},{"categories":["newsletter"],"date":"February 25, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/126/","section":"newsletter-archive","summary":"Tak jak pisałem już wcześniej - w AI interesują mnie praktyczne zastosowania i właśnie znalazłem jedno bardzo konkretne.\nKończę właśnie migrację mojej strony z Wordpressa na Hugo i jestem bardzo zadowolony jak dzięki AI (głównie LLM) sprawnie mi to poszło.\nDlaczego już nie mogłem wytrzymać Kilka lat temu zostałem namówiony na Wordpressa i do tej pory odczuwam konsekwencje tej decyzji. A dlaczego?\nOto kilka powodów, dla których już nigdy bym tego nie zrobił:\n- Fakt, Wordpress jest bardzo popularny, ale jest narzędziem z innej epoki i dla innego typu odbiorcy - głównie dla nietechnicznych ludzi, którzy potrzebują wyklikiwać swoje treści\n- Nie mam nic do php, ale to jak Wordpress opiera się na trylionach pluginów to jakiś koszmar. Przypomina mi to sytuację z Jenkinsem, gdy niewinna aktualizacja jednego pluginu wywala go całego. Tu jest podobnie.\nBaza danych, aby trzymać treści? Totalnie bez sensu. I do tego treść pomieszana z formatowaniem to później jeszcze większy bajzel. Poza tym wolę, abym backupem mojej strony było jedno repozytorium gita. Prostota wygrywa. Jakie to wolne! Sama strona może być już szybka (jak zainstalujesz odpowiednie pluginy), ale edycja to jakieś nieporozumienie. Mam (miałem?) wtyczkę Elementor i to jest nieporozumienie jakieś - każda edycja to załadowanie olbrzymiej ilości danych do przeglądarki i ciągłe odpytywanie backendu w PHP przy drobnej zmianie. Masakra… Ja potrzebuję czegoś lepszego i coś takiego już miałem wcześniej. To był Jekyll, który z kodu generował mi mojego bloga. To były wspaniałe czasy i postanowiłem naprawić mój błąd i wrócić do korzeni.\nDlaczego wybrałem Hugo Hugo to CMS napisany w Go w stylu Jamstack. Opiera się na szablonach, z których generowane są statyczne strony (HTML+Javascript).\nJest szybki w generowaniu i logicznie ułożony. Mogę w końcu zastosować moje podejście “Everything as Code” również do mojej strony!\nHugo jest naprawdę potężny, ale nie jest intuicyjny - przynajmniej nie na początku. Przypomina to trochę Kubernetesa - też na początku przeraża, ale później docenia się jak logicznie i prosty on jest.\nTo, że mam wszystko w postaci kodu powoduje, że mogę go hostować gdziekolwiek. Wcześniej używałem GitLab Pages lub GitHub Pages, a teraz wybrałem rozwiązanie Cloudflare Pages. Oczywiście ze względu na prostotę statycznych stron, usługi te są za friko. Dla mnie to jest tylko dodatek, bo większe korzyści widzę gdzie indziej.\nSkoro mam wszystko w kodzie to dzięki temu mogę:\nWersjonować wszystko w repo gita Mam lepszą kontrolę nad szablonami moich treści - oddzielnie tekst, oddzielnie forma Nie muszę klikać i mogę publikować z mojego edytora, a proces publikacji to zwykłe “git push” Jeśli będę chciał coś zmienić w układzie, dodać bajery (formularze, większa interaktywność) to mogę zatrudnić do tego AI No i apropos AI - użycie go bardzo, ale to bardzo ułatwiło mi migrację.\nJak migrowałem z AI Zanim o AI to jeszcze kilka rzeczy, które były konieczne przed.\nNajpierw kupiłem szablon, który mi się spodobał, bo żaden ze mnie grafik, a teraz jest tego na pęczki za kilkadziesiąt dolarów. Nie był idealny, ale to był dobry start.\nNastępnie użyłem Canvy do dopasowania wyglądu strony - tak, mam wersję płatną i to baaardzo ułatwia robienie takich rzeczy.\nPrzyszła pora na treści. Część utworzyłem od nowa, aby coś zmienić, poprawić, ale część zmigrowałem automatem. Użyłem projektu wp2hugo, który ułatwił mi co nieco, ale i tak musiałem dużą część poprawiać.\nI tu przychodzi część na AI. Posiadając szablon, częściowo zmigrowane treści i nie do końca pasujące mi elementy strony potrzebowałem sporo pozmieniać. Zatrudniłem sobie na początku bezpłatnego Copilota, który nawet dawał radę. Pomógł mi dostosowywać układy i nauczyć się zaawansowanych rzeczy z Hugo.\nPóźniej jednak zatrudniłem lepszego pomocnika - Cursor. I jestem pod wrażeniem. Świetnie radził sobie z zadaniami jakie mu dawałem. Znajdował odniesienia w całym kodzie, dodawał zmiany i sugerował ulepszenia. Co ciekawe odnalazł i naprawił nawet błąd w oryginalnym szablonie.\nTakie AI bardzo cenię - konkretne korzyści i oszczędności czasu. I może klikalne interfejsy są fajne dla laików, ale w dobie AI kod jest o wiele łatwiejszy dla agentów opartych o LLMy.\nI tak po tygodniu od rozpoczęcia migracji strony jestem już na jej ukończeniu. Pewnie w tym tygodniu opublikuję ostateczna jej wersję, a ty już możesz zobaczyć ją tutaj.\nNowe części serii “AI w minutę” Tradycyjnie na końcu przedstawiam listę dostępnych wideo tłumaczących jak działa AI.\n1: Jaka jest różnica między AI a LLM?\n2: Czym jest LLM?\n3: Jak powstaje LLM?\n4: Jaka działa LLM?\n5: Czym są parametry w LLM?\n6: Ile kosztuje korzystanie z LLM?\n7: Czym jest self-attention?\n8: Czym jest cutoff w LLM?\n9: Czym są tokeny?\n10: Czym są embeddings?\n11: Czym jest RAG?\n12: Czym jest prompt engineering?\n13: Jak uczyć AI z własnych danych?\n14: Dlaczego LLMy halucynują?\n15: Czym jest fine-tuning modelu? (niepubliczne - obecnie dostępne tylko dla subskrybentów)\n16: Czy korzystanie z LLM jest bezpieczne?\n17: Do czego potrzeba matematyki w LLM? (niepubliczne - obecnie dostępne tylko dla subskrybentów)\n18: Czym są agenty AI? (niepubliczne - obecnie dostępne tylko dla subskrybentów)\n19: AI w minutę: 19 - Co potrafią agenty AI? (już w czwartek 6 marca)\n","tags":["newsletter","hugo","wordpress","ai"],"title":"Newsletter #126 - Dłużej już nie mogłem wytrzymać"},{"categories":["newsletter"],"date":"February 18, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/125/","section":"newsletter-archive","summary":"Dzięki wszystkim za wypełnienie ankiety - dała mi dużo informacji i już przekłada się na moje działania. Ich rezultaty zobaczycie już niebawem.\nWylosowałem już 3 osoby i otrzymały one oddzielnego maila z zaproszeniem na rozmowę ze mną 1:1.\nA dzisiaj podważę długo utrzymywane założenie, że potoki CI/CD są najlepszym sposobem na tworzenie i wdrażanie oprogramowania. Wyjaśnię Ci czym jest podejście CI\u0026amp;CD.\nDlaczego tradycyjny potok CI/CD jest niedoskonały Klasyczny potok CI/CD łączy budowanie i wdrażanie w jeden zautomatyzowany przepływ. Podejście to ma jednak kilka istotnych wad:\nMarnotrawienie zasobów - Kompilacje są uruchamiane często, ale nie każda kompilacja musi zostać wdrożona, co prowadzi do niepotrzebnych procesów. Trudny i niepełny rollback - Wdrożenia tradycyjną częścią CD potoku konstruują (często na sznurki i gumę do żucia) manifesty i od razu je wdrażają na klastry przez co rollback jest złożony i niepełny, gdyż nie ma pełnych śladów o tym procesie CD Ścisłe powiązanie (tight coupling)- Podejście CI/CD ściśle łączy tworzenie i wdrażanie, zmniejszając elastyczność i zwiększając złożoność. Poznaj CI\u0026amp;CD Zamiast monolitycznego potoku CI/CD,oddzielamy procesy budowy i wdrażania:\nOddzielne budowanie z CI - Wykorzystaj istniejący silnik CI (np. Jenkins, GitHub Actions, GitLab CI), aby skupić się wyłącznie na budowaniu i testowaniu kodu. Wdrażanie za pomocą CD z GitOps - Tutaj pojawia się prawdziwa poprawa. Zdefiniuj pożądany stan aplikacji w repozytorium Git i użyj narzędzi GitOps, aby automatycznie zsynchronizować stan ze środowiskiem. Repozytorium Git staje się pojedynczym źródłem prawdy dla aplikacji. Kto powinien przyjąć to podejście?\nSkorzystają na tym duże organizacje ze złożonymi projektami, bo dzięki temu jest lepsza kontrola i możliwość audytu, a te są nieocenione przy zarządzaniu wdrożeniami na dużą skalę.\nRównież małe startupy ze świeżymi projektami (greenfield) zyskują na tym podejściu - rozpoczęcie od GitOps od samego początku buduje skalowalny i niezawodny proces wdrażania od podstaw.\nKorzyści nowego podejścia Przede wszystkim to olbrzymie oszczędności czasu. Nowe wersje są wcześniej udostępniane - skraca się TTM (Time To Market).\nZwiększona jest też transparentność - każda zmiana jest śledzona w Git, zapewniając wyraźną ścieżkę audytu wszystkich wdrożeń.\nPełny rollback jest możliwy i prostszy. Powrót do poprzedniego stanu odbywa się poprzez cofnięcie odpowiedniego commitu w repozytorium Git i zaczekanie, aż GitOps zrobi swoje.\nWspiera to również moje ulubione podejście “Everything as Code”. Bez tego tradycyjne potoki CI/CD wprowadzają chaos i niespójność.\nJak wdrożyć CI\u0026amp;CD O dziwo to dość proste:\nUżyj istniejącego silnika CI (Jenkins, GitHub Actions, GitLab CI) do budowy potoki CI, aby budować obrazy kontenerów i testować aplikacje. Taki potok wytwarza też manifesty, które automatycznie są commitowane do repozytorium. Wybierz dowolnego dostawcę Git (GitHub, GitLab, Bitbucket) i utwórz odpowiednią strukturę repozytoriów, wliczając to dedykowane “źródło prawdy” dla automatycznych wdrożeń przez GitOps. Połącz to z GitOps. Argo CD to obecnie najlepsze rozwiązanie dla większości przypadków użycia. Rozważ Flux CD dla mniejszych środowisk lub gdy potrzebujesz lekkiego rozwiązania. A czy takie wdrożenie jest łatwe?\nNo cóż, to podejście może początkowo stanowić wyzwanie, ale długoterminowe korzyści w postaci zmniejszonego nakładu pracy, zwiększonej niezawodności i szybszego TTM sprawiają, że inwestycja jest opłacalna. Doświadczone zespoły uznają to za łatwiejsze w zarządzaniu i jest to niezbędne dla zespołów, które chcą uniknąć ciągłej frustracji i niespójności środowisk.\nO tym podejściu będę tworzył dodatkowe, ciekawe treści. Temat jest bardzo interesujący dla dużej części z Was co potwierdziła ankieta.\nPlan jest, wkrótce realizacja 🙂\nNowe części serii “AI w minutę” Tradycyjnie na końcu przedstawiam listę dostępnych wideo tłumaczących jak działa AI.\n1: Jaka jest różnica między AI a LLM?\n2: Czym jest LLM?\n3: Jak powstaje LLM?\n4: Jaka działa LLM?\n5: Czym są parametry w LLM?\n6: Ile kosztuje korzystanie z LLM?\n7: Czym jest self-attention?\n8: Czym jest cutoff w LLM?\n9: Czym są tokeny?\n10: Czym są embeddings?\n11: Czym jest RAG?\n12: Czym jest prompt engineering?\n13: Jak uczyć AI z własnych danych?\n14: Dlaczego LLMy halucynują? (niepubliczne - obecnie dostępne tylko dla subskrybentów)\n15: Czym jest fine-tuning modelu? (niepubliczne - obecnie dostępne tylko dla subskrybentów)\n16: Czy korzystanie z LLM jest bezpieczne? (już w tłusty czwartek 27 lutego)\n","tags":["newsletter","cicd","gitops","argocd"],"title":"Newsletter #125 - Zapomnij o CI/CD"},{"categories":["newsletter"],"date":"February 11, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/124/","section":"newsletter-archive","summary":"Pomożesz mi? Chodzi o krótką ankietę. Szukam inspiracji na kolejne treści. Jak wypełnisz to masz szansę na spotkanie ze mną online 1:1. Szczegóły poniżej.\nWażna ankieta Potrzebuję Twojej pomocy. Jestem w kropce. Chcę pomóc ludziom z polskiej branży IT budować umiejętności z obszaru DevOps/Platform Engineeringu, ale nie jestem pewien, który kierunek obrać. I tu wchodzisz na białym koniu Ty.\nWystarczy, że wypełnisz poniższą, anonimową ankietę, a ja mogę wybrać Cię w drodze losowania jako jedną z 3 osób, z którymi spotkam się online na godzinną rozmowę (o ile oczywiście zechcesz i zostawisz swój email).\nW taki sposób pomogłem już wielu osobom, które kupiły ode mnie tą usługę, a ty możesz ją dostać zupełnie za friko. To jak - pomożesz mi wypełniając tą ankietę?\n📝 TAK, wypełniam i pomagam\nTylko do końca dnia dostępny Kubernetes po polsku ⏰ Dzisiaj o 21:00 kończy się promocyjna sprzedaż kursu. Sprawdź, a być może ostatnim rzutem na taśmę podejmiesz dobrą decyzję i w końcu zrozumiesz jak działa ten Kubernetes. Nawet jak na końcu to AI będzie pisał za Ciebie manifesty.\nPamiętaj, że AI zmieni najwięcej dla tych, którzy naprawdę rozumieją, jak działają systemy, a Kubernetes jest jednym z fundamentów, na których opiera się cała architektura nowoczesnych aplikacji. A wszyscy wiemy, gdzie będą uruchamiane aplikacje oraz agenty AI przez najbliższe lata – właśnie na platformach takich jak Kubernetes.\n👉 Sprawdź szczegóły kursu na oficjalnej stronie.\nNowe części serii “AI w minutę” Tradycyjnie na końcu przedstawiam listę dostępnych wideo tłumaczących jak działa AI.\n1: Jaka jest różnica między AI a LLM?\n2: Czym jest LLM?\n3: Jak powstaje LLM?\n4: Jaka działa LLM?\n5: Czym są parametry w LLM?\n6: Ile kosztuje korzystanie z LLM?\n7: Czym jest self-attention?\n8: Czym jest cutoff w LLM?\n9: Czym są tokeny?\n10: Czym są embeddings?\n11: Czym jest RAG?\n12: Czym jest prompt engineering? (niepubliczne - obecnie dostępne tylko dla subskrybentów)\n13: Jak uczyć AI z własnych danych? (już w poniedziałek 17 lutego)\n","tags":["newsletter","ai","ankieta"],"title":"Newsletter #124 - Ty mi, a ja Tobie"},{"categories":["newsletter"],"date":"February 4, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/123/","section":"newsletter-archive","summary":"Dla tych co czekali na mój kurs “Kubernetes po polsku” mam dobrą wiadomość - jest ponownie dostępny, a szczegóły na końcu.\nDzisiaj opiszę też dlaczego jesteśmy oszukiwani w sprawie AI i co z tym możemy zrobić.\nWyobrażenia Wyobraźcie sobie scenariusz, w którym to AI wykonuje za nas całą pracę. To wizja, która jest nam serwowana zewsząd. Nie będziemy już zmuszeni pisać linijek kodu, bo AI przejmie całe to zadanie i zaproponuje gotowe, dopracowane rozwiązania. Na czym to będzie polegać?\nOtóż, w magiczny sposób, wystarczy rzucić mu problem, a AI, niczym wszechwiedzący guru, wygeneruje perfekcyjne rozwiązanie. Proste kliknięcie w przycisk, \u0026ldquo;git push\u0026rdquo;, \u0026ldquo;kubectl apply\u0026rdquo;, \u0026ldquo;terraform apply\u0026rdquo; i voila! Nasza infrastruktura, aplikacje, wszystko działa idealnie, zautomatyzowane do granic możliwości i bez naszego większego wysiłku!\nNie będziemy musieli się więcej martwić o logikę i analizę, ponieważ AI przejmie całą tę odpowiedzialność, więc my będziemy mogli w końcu odpocząć i skupić się na ważniejszych zadaniach.\nDo tego każdy z nas, posiadając jedynie dostęp do ChatGPT lub innego modelu językowego, stanie się ekspertem w dowolnej dziedzinie - bo AI będzie nas w tym wspierać, usuwając bariery wejścia i przyspieszając naukę.\nRzeczywistość Niestety, rzeczywistość brutalnie weryfikuje te marzenia i idealistyczne podejście. Nie jest tak różowo, jak się nam to maluje w reklamach, a wręcz powiedziałbym, że jesteśmy oszukiwani kłamstwami grubymi nićmi szytymi. To, co obserwujemy w rzeczywistości to zupełnie inny obraz.\nOkazuje się, że generowany kod często wymaga dokładnego przejrzenia i sprawdzenia, czy nie ma tak zwanych \u0026ldquo;halucynacji\u0026rdquo;, czyli wymyślonych przez AI faktów i błędnych założeń.\nModele AI bazują na danych z przeszłości, więc często generowane rozwiązania wymagają dostosowania do najnowszych standardów, aktualnych wersji narzędzi oraz wymagań dotyczących bezpieczeństwa, które zmieniają się dynamicznie. Nie możemy zapominać o dostosowywaniu generowanego kodu pod specyfikę naszego środowiska, nasze własne obrazy, customowe endpointy usług, autoryzację i wiele innych, mniej oczywistych rzeczy. To nie jest uniwersalne rozwiązanie \u0026ldquo;one-size-fits-all\u0026rdquo;, jak to bywa przedstawiane.\nAI owszem dostarczy nam kod, ale co dalej?\nJak go poprawnie użyć? Jak go wdrożyć, aby był stabilny i dostępny? Co w przypadku, gdy coś przestanie działać? Jak w takim przypadku naprawić usterkę i gdzie szukać problemów? Bez głębszego zrozumienia całej architektury i niuansów działania danego rozwiązania, jesteśmy w pułapce i zgubieni. Musimy pamiętać też o tym, że wdrożenie to tylko wierzchołek góry lodowej, gdyż prawdziwa praca zaczyna się dopiero potem - dostosowanie pod zmienne wymagania, usprawnianie, optymalizacja, wprowadzanie zmian i rozwijanie całości systemu.\nCo to dla nas oznacza Zastanówmy się, co to wszystko tak naprawdę dla nas oznacza. Czy AI to tylko kolejne rozdmuchane hasło marketingowe, którego potencjał jest mocno przeceniany? Zdecydowanie nie! AI to potężne narzędzie, które ma szansę odmienić naszą pracę, ale musimy podejść do tego inaczej.\nAI przyniesie znacznie większe korzyści tym, co już posiadają wiedzę, bo to narzędzie jest potężne, ale wymaga doświadczenia i solidnych podstaw, aby w pełni wykorzystać jego potencjał. Samo poleganie na odpowiedziach AI nie wystarczy, bo rozumienie niczego nie zastąpi.\nMusimy NAJPIERW zrozumieć, jak działają dane technologie, aby LEPIEJ wykorzystać wiedzę i moc AI, która pokaże swoją prawdziwą siłę dopiero, gdy będziemy mieli solidne fundamenty i odpowiednie doświadczenie.\nNie możemy zakładać, że nagle staniemy się mistrzami DevOps, ponieważ to co utworzy AI to nie jest czarna skrzynka, a generowany kod wymaga zrozumienia, co tam się dzieje, abyśmy mogli go modyfikować, dodawać nowe elementy, a także szybko i sprawnie naprawiać błędy.\nJeśli dopiero zaczynamy swoją przygodę z technologią i mamy małą wiedzę, małe rozumienie tematów - to AI będzie dla nas głównie narzędziem do nauki, więc używajmy AI do nauki, ale nie polegajmy na nim w pełni przy wykonywaniu zadań produkcyjnych. Zdobądźmy wiedzę, doświadczenie i solidne podstawy, a wtedy AI faktycznie przyspieszy nasz rozwój.\nZ kolei, jeśli posiadamy solidną wiedzę i doświadczenie, AI możemy użyć do zlecania prostszych, powtarzalnych zadań, aby przyspieszyć naszą pracę, oszczędzając czas na bardziej skomplikowane i strategiczne działania.\nW czasach AI, gdzie nie musimy już skupiać się na żmudnym pisaniu kodu, myślenie jest na wagę złota, a to właśnie logiczna analiza, krytyczne podejście oraz umiejętność rozwiązywania problemów to kluczowe umiejętności w dynamicznym świecie IT. To co musimy doskonalić to rozumienie, analiza i krytyczne podejście do tego, co generuje AI, bo to nam umożliwi wykorzystanie jej w pełni.\n#MyślenieJestWcenie. Również w czasach AI.\nKubernetes po polsku dostępny do 11 lutego Wiele osób pisało do mnie i czekało na ten moment – otwieram sprzedaż części PRO mojego kursu \u0026ldquo;Kubernetes po polsku\u0026rdquo;. To w niej znajdziesz najbardziej zaawansowane treści i praktyczne umiejętności, które pozwolą Ci zrozumieć Kubernetes na poziomie eksperckim.\nPamiętaj, że AI zmieni najwięcej dla tych, którzy naprawdę rozumieją, jak działają systemy, a Kubernetes jest jednym z fundamentów, na których opiera się cała architektura nowoczesnych aplikacji. A wszyscy wiemy, gdzie będą uruchamiane aplikacje oraz agenty AI przez najbliższe lata – właśnie na platformach takich jak Kubernetes.\nSzczegóły znajdziecie na stronie kursu.\n⏰ Sprzedaż trwa tylko do 11 lutego. Zatem jest kilka dni na poszukanie środków z budżetu szkoleniowego w firmie lub zainwestowanie w siebie z prywatnego.\nNowe części serii “AI w minutę” Tradycyjnie na końcu przedstawiam listę dostępnych wideo tłumaczących jak działa AI.\n1: Jaka jest różnica między AI a LLM?\n2: Czym jest LLM?\n3: Jak powstaje LLM?\n4: Jaka działa LLM?\n5: Czym są parametry w LLM?\n6: Ile kosztuje korzystanie z LLM?\n7: Czym jest self-attention?\n8: Czym jest cutoff w LLM?\n9: Czym są tokeny?\n10: Czym są embeddings? (niepubliczne - obecnie dostępne tylko dla subskrybentów)\n11: Czym jest RAG? (już w poniedziałek 10 lutego)\n","tags":["newsletter","rozwoj","ai"],"title":"Newsletter #123 - Dlaczego nas okłamują z tym AI"},{"categories":["newsletter"],"date":"January 28, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/122/","section":"newsletter-archive","summary":"Ale się porobiło! Jeszcze tydzień temu temat, o którym dzisiaj piszę, miałby zupełnie inny wydźwięk. A tu w poprzedni poniedziałek został opublikowany nowy model DeepSeek-R1.\nTak to wszystko wywróciło, że odwołuję webinar z tego tygodnia, ale spokojnie - są kolejne wideo z serii “AI w minutę”.\nAI zacierają (zacierały?) ręce na AI Cóż to za piękne czasy nastały dla CEO i akcjonariuszy wielkich firm, które w jakikolwiek sposób tworzą coś z AI. Mówię tu głównie o gigantach typu Nvidia, Microsoft, Google, Amazon, ale też OpenAI planujące zmonetyzować sukces swoich modeli GPT.\nDlaczego? Oto najważniejsze powody:\nModele AI (LLM i inne) wymagają do wytrenowania danych, ale głównie mocy obliczeniowej. Do tego używa się drogich kart GPU i ci co je mają lub produkują, patrzą na słupki rosnących cen akcji i planują wcześniejsze emerytury. Nawet jak nie produkujesz kart GPU (czyli nie jesteś firmą Nvidia) to nadal możesz wskoczyć na ten okręt, gdyż nie tylko potrzeba kart GPU, ale też dużo prądu, storage i compute do serwowania tych modeli klientom płacącym za tokeny wysyłane do modeli.\nKilka dni temu ogłoszono, że pewna grupa firm zainwestuje 500 miliardów dolarów w taką infrastrukturę przewidując spory popyt na AI uruchamianie w nowiutkich datacenter. W przeciwieństwie do “zwykłych” aplikacji uruchamianych od kilkunastu już lat w chmurze, aplikacje/agenty i modele AI mają zdecydowanie większą grupę odbiorców. Oznacza to, że będzie to jeszcze bardziej dochodowe. \u0026lt;sarkazm\u0026gt;Wymazywanie nieznajomych z naszych fotek z wakacji\u0026lt;/sarkazm\u0026gt;, ale też inne i naprawdę ważne zastosowania mają już grupę odbiorców, która będzie tylko rosła. Nawet jak organizacje pragnące użyć modeli zechcą je uruchomić na własnych serwerach to… i tak będą potrzebowały kupić karty GPU. Gdzieś dolary i tak wyślą. I to było prawdą do czasu opublikowania chińskiego modelu DeepSeek-R1. To spowodowało olbrzymie zawirowanie, ponieważ:\nTen model został wytrenowany o wiele, wiele taniej. Niektóre źródła mówią o 3-5% kosztów modelu GPT-4o (podobno 5-6 milionów dolarów). Ich model okazuje się dorównywać i czasem prześcigać w testach głównego, o wiele droższego rywala GPT-4o. W przeciwieństwie do modeli od OpenAI model DeepSeek jest nie tylko możliwy do uruchomienia lokalnie (jest już do uruchomienia na Ollama), ale też open source. Oznacza to, że teraz inni będą mogli stworzyć podobne modele również taniej. To spowodowało niezłe zawirowania na giełdzie, bo inwestorzy przestają wierzyć w zapewnienia CEO tych wielkich amerykańskich korporacji o olbrzymich zyskach, skoro można będzie taniej tworzyć i uruchamiać takie modele. I to poza chmurą.\nTo pewien prztyczek w nos na Chin w stronę USA, ale ten newsletter jest o technologii, a nie polityce więc zostawię to jako ciekawostkę.\nCo się wydarzy dalej? Z pewnością jest to bardziej optymistyczne i bardziej demokratyczne podejście do AI w duchu open source.\n🍿 Zobaczymy co przyniesie najbliższa przyszłość.\nOdwołany webinar Jestem zmuszony odwołać webinar zaplanowany na najbliższy czwartek. To głównie przez to co się wydarzyło z ogłoszeniem DeepSeek i stwierdziłem, że potrzebuję więcej czasu na przygotowanie treści mającej odwołanie do tej nowej rzeczywistości.\nPrzepraszam, ale co się odwlecze to nie uciecze.\nDo tego czasu oczywiście będę publikował nowe wideo z serii “AI w minutę” i dalej zgłębiał praktyczne strony AI.\nNowe części serii “AI w minutę” Przedstawiam dostępne wideo z mojej treściwej serii filmów o AI. Skończyłem nagrywanie kolejnych części - będzie ich łącznie 22.\nTrwa ich montaż, gdyż pomimo, że każdy z nich trwa około minuty to ich przygotowanie jest o wieeeele dłuższe.\n1: Jaka jest różnica między AI a LLM?\n2: Czym jest LLM?\n3: Jak powstaje LLM?\n4: Jaka działa LLM?\n5: Czym są parametry w LLM?\n6: Ile kosztuje korzystanie z LLM?\n7: Czym jest self-attention?\n8: Czym jest cutoff w LLM? (niepubliczne - obecnie dostępne tylko dla subskrybentów)\n9: Czym są tokeny? (już w poniedziałek 3 lutego)\n","tags":["newsletter","rozwoj","ai","strategia"],"title":"Newsletter #122 - Czy AI będą kontrolować korporacje"},{"categories":["newsletter"],"date":"January 21, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/121/","section":"newsletter-archive","summary":"Dzisiaj mam dla Ciebie trzy ważne rzeczy. Pierwsza to moje wnioski z tego co zmienia AI dla DevOps, druga to kolejne części serii “AI w minutę”, a ostatnia to informacja o nadchodzącym webinarze.\nCo zmienia AI dla DevOps Niby nikt kto pracuje w obszarze DevOps nie ma się niczego obawiać, ale jest kilka rzeczy, o których warto wiedzieć i być odpowiednio przygotowanym.\nPrzedstawiam Ci zatem szanse i zagrożenia jakie niesie ze sobą AI.\n🟢 Szanse\nSzybciej tworzone rozwiązania dla platform.\nZ ChatGPT i rozwiązaniami typu GitHub Copilot (szczególnie jak stał się darmowy) pisanie Dockerfile, modułów do Terraform/OpenTofu czy Helm Chartów staje się szybsze i przyjemniejsze.\nTo przyczyni się do większej produktywności lub odzyskania czasu na inne, ważniejsze rzeczy.\nŁatwiejszy troubleshooting i nauka.\n“Co oni tam powyprawiali?” - pomyślał niejeden DevOps. Diagnozowanie tajemniczych problemów staje się szybsze dzięki AI. A może dzięki temu coraz więcej osób ogarnie observability i posiądzie wiedzę o tracingu? W tym też może pomóc AI, bo może nam odpowiedzieć szybko na wiele nurtujących pytań.\nDevOps będzie niezbędny do obsługi modeli AI.\nTo najważniejsza według mnie szansa. Modele LLM czy inne, będą uruchamiane jak usługi w chmurze lub lokalnie. Tak naprawdę to będą przypominać tradycyjne aplikacje korzystające z GPU.\nPotrzebna będzie zatem wiedza o sieci, infrastrukturze, monitoringu, observability, CI/CD dla deploymentu modeli i wszystko to czym DevOps zajmował się do tej pory. Dojdzie po prostu kolejny obszar do ogarniania. Zatem czas zakasać rękawy!\n🟠 Zagrożenia\nWięcej ludzi bez wiedzy zacznie tworzyć “potworki”.\nSkoro można zlecić utworzenie konfiguracji dla Kubernetes, manifestu dla Terraform/OpenTofu, to po co zawracać głowę ludziom od DevOps?\nI tak będą powstawać różne rozwiązania, które mogą stworzyć wiele zagrożeń. Bez odpowiedniej wiedzy nie da się zweryfikować AI, które halucynuje i bez kontekstu podaje generyczne, często nieaktualne rozwiązania. A utworzenie konfiguracji to zaledwie początek drogi, gdyż późnieju trzeba to utrzymywać i diagnozować.\nWiększy próg wejścia do DevOps dla juniorów.\nTo już jest zauważalne. Z reguły osoby bez dużego doświadczenia wykonują prostsze prace zlecane przez ich bardziej doświadczonych kolegów i koleżanki z zespołu.\nNo a teraz zamiast zlecać zadania juniorom zostaną one zlecone AI. Model szybciej wygeneruje coś co napisałby junior(ka), a senior(ka) rzutem oka sprawdzi i ewentualnie doszlifuje to do potrzeb.\nCoraz więcej nacisku będzie kładzione na zrozumienie koncepcji niż jej ostatecznie zaimplementowanie.\nPrzyszłe agenty AI będą same zarządzać platformami.\nŻaden Puppet, Ansible czy Kubernetes nie zagraża pracy tak jak możliwe rozwiązania AI w postaci autonomicznych agentów. To jeszcze melodia przyszłości, ale całkiem możliwa.\nWolałbym, aby takie agenty wykonywały brudną pracę, a dla DevOps zostało opracowanie architektury czy optymalizacja. Czas pokaże w którą stronę to pójdzie.\nNowe części serii “AI w minutę” Są już nowe wideo mojej treściwej serii filmów o AI. Od teraz będę załączał listę tych dostępnych publicznie oraz tych, które jeszcze publiczne nie są, ale ty możesz je już obejrzeć korzystając z linka.\n1: Jaka jest różnica między AI a LLM?\n2: Czym jest LLM?\n3: Jak powstaje LLM?\n4: Jaka działa LLM?\n5: Czym są parametry w LLM?\n6: Ile kosztuje korzystanie z LLM? (niepubliczne - obecnie dostępne tylko dla subskrybentów)\n7: Czym jest self-attention? (już w poniedziałek 27 stycznia)\nObalamy największe bzdury i mity o AI - webinar Już teraz zarezerwuj sobie czas w czwartek 30 stycznia o 19:00 na pierwszy webinar, gdzie opowiem o legendach i powielanych bzdurach, mitach i półprawdach o AI.\nDowiesz się tam między innymi:\n- Czy AI to bańka i kiedy pęknie?\n- Kogo zastąpią agenty AI?\n- Czy jest sens pisać soft skoro jest AI?\n- Czy trzeba umieć matmę, aby pisać aplikacje z LLM?\n🗓️Dodaj do kalendarza Google | 🗓️Dodaj do kalendarza Outlook\n","tags":["newsletter","ai","devops","strategia"],"title":"Newsletter #121 - Co ma DevOps do AI "},{"categories":["learning"],"date":"January 13, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/learning/kurs-ai-w-minute/","section":"learning","summary":"","tags":["kurs","ai","llm"],"title":"(PL) Kurs AI w Minutę"},{"categories":["newsletter"],"date":"January 7, 2025","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/120/","section":"newsletter-archive","summary":"Nowy rok, nowe wyzwania, postanowienia i nowe treści. Sprawdź informacje o tym co w najbliższych tygodniach znajdziesz u mnie.\nAI w minutę - pierwsze odcinki Żyjemy w ciągłym niedoczasie. Jednocześnie kto nie chciałby dowiedzieć się czegoś ciekawego o nowej technologii?\nJeśli czytasz regularnie lub okazjonalnie przeglądasz ten newsletter to pewnie właśnie z myślą o rozwoju.\nTo się doskonale składa, bo właśnie rozpoczynam nowy cykl filmów - “AI w minutę”.\nBędą to krótkie wideo o długości około minuty o dużym zastrzyku przydatnej wiedzy o sztucznej inteligencji wraz z obrazowym opisem (w sam raz dla wzrokowców jak ja).\nTo po to, abyś zaznajomił się z najważniejszymi terminami oraz zasadą działania AI nie spędzając godzin przed nudnymi materiałami.\nJa już za Ciebie czytam książki, publikacje, dokumentacje i przeglądam inne materiały, aby dać Ci potężną pigułę wartościowej wiedzy.\nSą już dostępne dwa odcinki:\n1 - Jaka jest różnica między AI a LLM? 2 - Czym jest LLM? (niepubliczny) Czytaj ten newsletter, a będziesz mógł oglądać filmy wcześniej i dowiesz się zawczasu o wydarzeniach na żywo (planuję wkrótce serie webinarów).\nPostanowienie noworoczne Niektórzy wyśmiewają pomysł stawiania noworocznych postanowień. Ja wówczas przypominam sobie, że część osób (według niektórych badań jest to około kilkunastu procent) dotrwa dłużej niż kilka dni lub tygodni zamieniając postanowienie w nawyk.\nDlatego ja nie jestem sceptyczny - niech to będzie nawet 10% szans na zmianę. To całkiem sporo i zawsze warto próbować. Mi niektóre rzeczy zajęły lata, bo zmiany nie są łatwe. Szczególnie te duże i ważne.\nJa postanowiłem postawić na lepszy sen. To pozwoli odzyskać trochę czasu i pozwolić mojemu mózgowi na lepsze funkcjonowanie.\nPrzede mną pracowite tygodnie nad nowymi materiałami. Trzymam kciuki za wszystkich, którzy też z nadzieją stawiają sobie nowe cele - powodzenia!\n","tags":["newsletter","ai","kurs"],"title":"Newsletter #120 - AI dla zabieganych"},{"categories":["newsletter"],"date":"December 17, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/119/","section":"newsletter-archive","summary":"Dziś przyjrzymy się gorącemu tematowi – sztucznej inteligencji (AI) w DevOps. Nie chodzi o mgliste obietnice, ale o to, jak faktycznie AI jest wykorzystywane i dokąd zmierzamy.\nOstatnio sporo o tym myślę i na bazie doświadczeń i najnowszego raportu State of Devops 2024 mam kilka przemyśleń którymi chcę się z Tobą podzielić.\nTak AI używa większość Zacznijmy od faktów. Jak obecnie większość z nas wykorzystuje AI? Przede wszystkim jako:\nPomoc w diagnozowaniu problemów: zamiast przekopywać tonę dokumentacji i logów, pytamy AI o sugestie rozwiązań. To trochę jak konsultacja z mądrym kolegą, który zna odpowiedź. Szybsze uczenie się: zapominamy o googlowaniu i polegamy na AI jako pierwszym źródle wiedzy. Tak! Ja sam przy nauce AI robię dokładnie tak samo i jest to całkiem przyjemne. Wspomaganie pisania kodu: AI jest pomocne w generowaniu Dockerfile, definicji potoków CI/CD (np. dla GitLab CI, GitHub Actions) – czyli codziennych zadań DevOps. Oczywiście musimy to sprawdzać, ale to i tak duża oszczędność czasu. Potwierdza to najnowszy raport State of Devops 2024, który jasno pokazuje, że AI jest już na pokładzie w wielu organizacjach. Tylko wiecie co? Szału nie ma. Raport nie pokazuje rewolucji. AI jest, ale nie rewolucjonizuje jeszcze naszej pracy. Raczej wspomaga niż zastępuje. Nie szykuje się żaden Skynet, przynajmniej na razie :)\nLiczyliśmy chyba na więcej Spójrzmy prawdzie w oczy. Większość z nas korzysta z AI głównie w interaktywnych sesjach chat z ChatGPT czy innymi LLMami. I to jest pomocne, to na pewno, ale czy to nie za mało? Czy nie powinniśmy oczekiwać więcej?\nOsobiście liczyłem na większy skok.\nW DevOps, gdzie automatyzacja jest fundamentem, używanie AI głównie jako \u0026ldquo;pomocnika\u0026rdquo; do zadań, które moglibyśmy (i powinniśmy!) zautomatyzować, to marnowanie potencjału. Powinniśmy wykorzystać AI do\u0026hellip; no właśnie, do czego?\nPrzyszłość to Autonomiczne Agenty AI - to jest ta prawdziwa rewolucja, na którą ja osobiście czekam.\nMoim zdaniem prawdziwa przyszłość AI w DevOps to autonomiczne agenty. To nie są już tylko narzędzia wspierające. To są byty, które potrafią:\nSamodzielnie rozwiązywać problemy (lub przynajmniej próbować): AI nie tylko podpowie rozwiązanie, ale sama je wdroży i sprawdzi, czy to zadziałało. Opiniować pull requesty kodu infrastruktury, a nawet go poprawiać: Koniec z nudnymi code review - agenty AI wyłapią błędy i zaproponują lepsze rozwiązania. Pisać potoki CI/CD: Agenty mogą same generować definicje CI/CD dla GitLab CI, GitHub Actions, uwzględniając najlepsze praktyki. Sprawdzać ORAZ naprawiać luki w bezpieczeństwie: Bezpieczeństwo nie będzie już tylko checklistą, ale ciągłym, zautomatyzowanym procesem. Pisać kod Terraform/OpenTofu dla infrastruktury: Moduły infrastruktury stają się o wiele szybsze i łatwiejsze do tworzenia z pomocą AI. To właśnie TO jest przyszłość, w którą wierzę. To jest zmiana, która faktycznie zrewolucjonizuje naszą pracę i to o tym będę tworzył treści.\nCo więcej - to jest obiecana przyszłość o której wspominałem już w jednym z newsletterów.\nCo dalej? To ostatni newsletter w tym roku, ale w 2025 spodziewaj się webinarów i warsztatów o praktycznym zastosowaniu AI w DevOps, a w szczególności o tworzeniu takich agentów.\nChcę Ci pokazać, jak zbudować autonomiczne AI i uwolnić się od rutynowych zadań.\nJa już piszę takie agenty i wkrótce ujawnię więcej szczegółów.\nSprawdź moje nowe wideo Nagrałem wideo, które może Cię zainteresować. Nie jest techniczne, jest bardziej dające do myślenia, gdyż takie treści będą u mnie teraz przeważać.\nObejrzyj czym jest punkt znikających korzyści i nie wpadaj w pułapkę, które nastawiają na nas firmy.\n","tags":["newsletter","ai","strategia"],"title":"Newsletter #119 - Tak AI powinno nas wspomagać"},{"categories":["newsletter"],"date":"December 10, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/118/","section":"newsletter-archive","summary":"Tak dużo osób pracuje z Kubernetesem i wdraża aplikacje, a ja się spotykam wciąż z pytaniami jak zrobić to najlepiej. I wówczas odpowiadam jak każdy konsultant - “to zależy”. Liczy się kontekst i dlatego dzisiaj przedstawiam Ci koncept złotej ścieżki (Golden Path),\nTyle opcji do budowy CI/CD\u0026hellip; a Ty wciąż błądzisz? Obecnie potoki CI/CD są niezbędne do szybkiego i efektywnego wdrażania aplikacji. Problem w tym, że wybór narzędzi i technik CI/CD jest ogromny. Jenkins, GitLab CI, GitHub Actions, CircleCI, Travis CI… lista wydaje się nieskończona.\nDodajmy do tego Kubernetes, który sam w sobie jest ekosystemem o niewyobrażalnej złożoności. Efekt? Zespoły często gubią się w tym gąszczu możliwości, tracąc cenny czas na bezowocne poszukiwania idealnego rozwiązania.\nZamiast skupiać się na budowaniu aplikacji, walczą z konfiguracją narzędzi, tworząc własne, często suboptymalne rozwiązania, bo \u0026ldquo;przecież nasze jest lepsze\u0026rdquo;. Brzmi znajomo? To właśnie pułapka \u0026ldquo;not invented here\u0026rdquo;, która kosztuje firmy ogromne nakłady czasu i zasobów.\nDlatego dziś chcę podzielić się z Tobą kluczową ideą, która może odmienić Twój workflow CI/CD - koncept Golden Path, czyli złotej ścieżki.\nGolden Path: zbuduj własny standard Zamiast błąkać się bez celu po labiryncie narzędzi CI/CD, wytycz sobie jasną ścieżkę – Golden Path.\nTo nie jest sztywny przepis, lecz elastyczny szablon, który pozwala na zbudowanie spójnego i efektywnego procesu wdrażania oprogramowania w Twojej organizacji.\nPoczątek to eksploracja – przetestowanie różnych narzędzi i podejść. Nie bój się eksperymentować, ale pamiętaj, że kluczem do sukcesu jest ustalenie wspólnego standardu.Wybierz narzędzia i techniki, które najlepiej odpowiadają specyfice Twojej firmy i projektu.\nNastępnie, zdefiniuj jasne procedury i procesy, od budowania obrazów kontenerów (Docker, Buildpacks – wybór zależy od Twoich potrzeb) po wdrażanie do Kubernetes, zarządzanie konfiguracją (Helm, Kustomize – znów, kluczem jest spójność), kontrola wersji i uprawnienia dostępu.\nNie zapominaj o wersjonowaniu – stabilne, przetestowane wersje to podstawa efektywnej pracy. Do tego pozwoli to użytkownikom na wdrożenie zmian dostępnych w kolejnej wersji według swojego harmonogramu.\nPosiadanie takiej złotej ścieżki nie oznacza, że wszyscy muszą budować i wdrażać tak samo. Dodaj opcje konfiguracji, aby dać pewne pole manewru. To lepsze od zupełnie nowej wersji, a daje poczucie autonomii i pozwala na większą elastyczność.\nCzas to pieniądz Zastanów się, ile czasu Twój zespół traci na rozwiązywanie problemów wynikających z niespójności w procesie CI/CD. Golden Path to recepta na odzyskanie tego cennego zasobu. Ujednolicony proces oznacza:\nSzybsze wdrażanie: Mniej błędów, mniej czasu spędzonego na debugowaniu. Zwiększona stabilność: Spójne środowisko pracy i łatwiejsze utrzymanie. Lepsza współpraca: Zespoły pracują w oparciu o wspólne standardy, co ułatwia komunikację i wymianę wiedzy. Skalowalność: Łatwiejsze rozszerzanie i dostosowywanie systemu CI/CD do zmieniających się potrzeb. Oszczędność kosztów: Mniej błędów oznacza mniej czasu poświęconego na naprawianie, a to przekłada się na oszczędność. Golden Path nie oznacza rezygnacji z innowacji. Wręcz przeciwnie – pozwala na systematyczne wprowadzanie ulepszeń, testując nowe technologie w ramach ustalonego frameworku.\nMożesz dostosować Golden Path do specyfiki Twojej firmy, zapewniając elastyczność i jednocześnie utrzymując spójność. To inwestycja, która zwraca się wielokrotnie w postaci zaoszczędzonego czasu, zwiększonej efektywności i zadowolenia Twojego zespołu.\nWidziałem wielokrotnie jak organizacje się męczą i wynajdują koło od nowa. Szkoda czasu. Szczególnie, że przed nami więcej wyzwań i możliwości (tak, mówię tu o AI).\n👉 Obejrzyj to wideo, gdzie omawiam ten koncept w większych szczegółach i pokazuję rysując jego główne założenia.\nJedziesz na KubeCON EU w Londynie? Tylko do 17 grudnia są najtańsze bilety - sprawdź na stronie wydarzenia. Ja już mój kupiłem i się wybieram.\n","tags":["newsletter","cicd","goldenpath","kubernetes","devops"],"title":"Newsletter #118 - Czym jest Golden Path dla CI/CD"},{"categories":["newsletter"],"date":"December 3, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/117/","section":"newsletter-archive","summary":"W tym newsletterze opowiem Ci o efekcie Krugera-Dunninga – zjawiska, które wpływa na naszą samoocenę w trakcie nauki. To naturalny proces, który warto zrozumieć, aby uniknąć pułapek i skutecznie wykorzystać go do własnego rozwoju.\nA dlaczego o nim chcę dzisiaj napisać? Bo sam się z nim obecnie zmierzam ucząc się o LLM i AI.\nDopadł mnie Krugera-Dunninga – przygoda z AI Obecnie intensywnie uczę się AI. Początkowo byłem pełen entuzjazmu – pierwsze sukcesy, proste zadania, wszystko szło gładko.\nCzułem się jak ryba w wodzie, czułem przypływ energii, zacząłem to wszystko rozumieć i wykorzystywać uśpioną wiedzę z matematyki.\nAle im dalej w las, tym bardziej zdaję sobie sprawę z ogromu mojej niewiedzy. To właśnie ten spadający odcinek krzywej Krugera-Dunninga. Wiem, że to normalne i że kluczem jest akceptacja tego faktu, a nie zniechęcanie się nad sobą.\nFajnie jest się czasem poczuć dobrze i pooszukiwać, że jest się daleko. Z doświadczeniem przychodzi jednak większa tolerancja, a z wiedzą o tym jak działa mózg większy spokój i właśnie ta akceptacja.\nOd \u0026ldquo;Jestem ekspertem!\u0026rdquo; do \u0026ldquo;Nic już nie wiem\u0026rdquo; Każdy, kto uczył się czegoś nowego, zna to uczucie: na początku, kiedy znajomość tematu jest niewielka, czujemy się często nadzwyczaj pewni siebie.\nPierwsze sukcesy, szybkie postępy i łatwe zadania utwierdzają nas w przekonaniu o własnych umiejętnościach. Mówimy sobie: \u0026ldquo;To banalne!\u0026rdquo;, \u0026ldquo;Ogarniam to!\u0026rdquo;, \u0026ldquo;Jestem w tym dobry!\u0026rdquo;. Jednak wraz z pogłębianiem wiedzy, zaczynamy odkrywać nowe, bardziej złożone aspekty tematu. Dostrzegamy luki w naszej wiedzy, zdajemy sobie sprawę z pułapek, z którymi się wcześniej nie zetknęliśmy.\nTen początkowy entuzjazm ustępuje miejsca bardziej realistycznej, a czasami nawet pesymistycznej, samoocenie. Pewność siebie spada, ale jednocześnie rośnie nasza świadomość i rzeczywista wiedza. To właśnie jest sedno efektu Krugera-Dunninga – to taka odwrócona podróż w stylu Benjamina Buttona - od \u0026ldquo;eksperta\u0026rdquo; do \u0026ldquo;pokornego ucznia\u0026rdquo;.\nDlaczego Tak Się Dzieje Efekt ten wynika z ograniczonej wiedzy i braku świadomości o złożoności tematu. Na początku nauki, nie mamy odpowiedniego punktu odniesienia, który pozwoliłby nam realnie ocenić własne umiejętności. Wraz z postępem, nasze postrzeganie zmienia się.\nZaczynamy dostrzegać, jak wiele aspektów tematu wcześniej pomijaliśmy, jak wiele jeszcze musimy się nauczyć. Ten proces, chociaż może być trudny emocjonalnie, jest niezbędny do rozwoju prawdziwej kompetencji.\nNie chodzi o to, aby zatracić całkowicie pewność siebie, ale o to, aby zbudować realistyczną samoocenę opartą na rzeczywistej wiedzy i doświadczeniu.\nJak wykorzystać to na własną korzyść Efekt Krugera-Dunninga, choć może wydawać się problematyczny, to w rzeczywistości jest niezwykle cennym narzędziem do motywacji i postępu. Początkowy entuzjazm jest silnym napędem do nauki i podejmowania wyzwań. Aby go skutecznie wykorzystać, warto:\nAkceptować wahania - są one naturalne. Nie zniechęcaj się, gdy po początkowym optymizmie nawiąże się okres większej niepewności. Koncentrować się na procesie - Skup się na systematycznej nauce i robieniu postępów, a nie na szybkości osiągania sukcesów. Celebrować małe sukcesy - Nagradzaj się za każdy krok naprzód, aby utrzymywać wysoki poziom motywacji. Efekt Krugera-Dunninga to naturalny proces uczenia się. Nie walcz z nim, tylko naucz się go rozumieć i wykorzystywać na swoją korzyść.\n","tags":["newsletter","rozwoj","edukacja","strategia"],"title":"Newsletter #117 - Mnie dopadł i pewnie Ciebie też \\- efekt Krugera-Dunninga"},{"categories":["newsletter"],"date":"November 26, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/116/","section":"newsletter-archive","summary":"Uczę się intensywnie, czytam, sprawdzam i rozmyślam. Z tego wkrótce powstaną nowe treści, ale już teraz podzielę się z Tobą wnioskami dotyczącymi wpływu AI na naszą branżę IT.\nPrzypominam też, że tylko do dzisiaj trwa promocja na mój nowy kurs o GitLab CI. Szczegóły na końcu.\nDlaczego nie możesz już ignorować AI Sztuczna inteligencja, szczególnie modele językowe dużego rozmiaru (LLM) takie jak GPT, są już faktem, który rewolucjonizuje nie tylko branżę IT, ale też wiele innych sektorów. Ja skupię się na naszej, czyli IT.\nChociaż zawsze znajdą się sceptycy nowych technologii (podobnie jak było z smartfonami, chmurą obliczeniową czy Kubernetesem), ignorowanie AI jest obecnie strategicznym błędem. Trend jest niepodważalny: firmy inwestują ogromne sumy w AI, widząc w niej klucz do utrzymania konkurencyjności i przetrwania na coraz bardziej dynamicznym rynku.\nDowodem na to są spektakularne sukcesy relatywnie małych firm wykorzystujących AI, a także dane dotyczące kapitału venture capital pompowanego w startupy i firmy zaawansowane technologicznie.\nRozwój AI wpływa na decyzje biznesowe, w tym na alokację budżetów i priorytetyzacji projektów - słyszę o tym często w rozmowach z ludźmi.\nCo mnie osobiście przekonało Początkowo podchodziłem do AI z pewną dozą sceptycyzmu, podobnie jak wielu innych. Potrzebowałem zobaczyć praktyczne zastosowanie, coś, co realnie usprawni moją pracę i przyniesie wymierne korzyści. Zmiana nastąpiła po pewnym czasie sprawdzania, testowania i rozmów z ludźmi z branży.\nKluczowe okazały się nie tylko dane dotyczące inwestycji firm w AI, ale również obserwacja, że firmy aktywnie poszukują specjalistów z tej dziedziny. Ciekawym przykładem jest tu informacja o oszczędności 4500 lat pracy deweloperów w AWS dzięki wykorzystaniu AI do refaktoringu kodu Javy. To pokazuje skalę możliwości, jakie oferuje AI, a także jej wpływ na efektywność i produktywność.\nFirmy to widzą, a zatem będą szukać podobnych zastosowań u siebie. Tego trendu się już nie da zatrzymać. Potrzebujemy znaleźć w tym miejsce dla siebie i sposób, aby to wykorzystać dla korzyści swojej i organizacji.\nAle wciąż będzie mnóstwo pracy wokoło LLM Chociaż AI z pewnością automatyzuje wiele procesów i usprawnia pracę, nie oznacza to, że zastąpi ona nas całkowicie - to mrzonki i brednie. Wręcz przeciwnie, powstanie zapotrzebowanie na nowe role i specjalizacje związane z wdrażaniem, utrzymaniem i bezpieczeństwem modeli LLM (np. LLM Ops, AI Security Engineer, Prompt Engineer).\nFirmy będą musiały zmierzyć się z wieloma znanymi nam już wyzwaniami, takimi jak zapewnienie bezpieczeństwa danych, integracja modeli AI z istniejącą infrastrukturą, monitorowanie wydajności i niezawodności systemów, a także zarządzanie kosztami, które w przypadku LLM mogą być znaczące.\nZatem, niezależnie od tego, czy jesteś DevOps-em czy inżynierem oprogramowania, czeka cię decyzja - jak moje obecne umiejętności mogę wykorzystać dla środowisk z modelami LLM lub wzmocnić swoją pozycję poprzez użycie odpowiednich narzędzi AI.\nTa jedna rzecz, w której AI nas nie zastąpi to… Pomimo postępu technologicznego, AI nie jest w stanie zastąpić ludzkiej kreatywności, intuicji i zdolności do empatycznego rozumienia kontekstu.\nChociaż AI może wspomagać procesy twórcze, generując pomysły lub automatyzując powtarzalne zadania, to generowanie innowacyjnych pomysłów, rozwiązywanie złożonych problemów i budowanie relacji z ludźmi pozostanie domeną ludzi.\nAI będzie tylko narzędziem w naszych rękach, potężnym i wszechstronnym, ale to my będziemy nadal sterować procesem, nadawać kierunek i decydować o tym, jak wykorzystać jej potencjał.\nNastąpi, a w pewnym stopniu już następuje, przekierowanie naszej energii i czasu z wykonywania powtarzalnych zadań na bardziej kreatywne i strategiczne działania, co ostatecznie doprowadzi do zwiększenia naszej produktywności i satysfakcji z pracy.\n⏰ Dzisiaj koniec promocji na najnowszy kurs Tak jak pisałem tydzień temu - opublikowałem nowy kurs: SkillBooster GitLab CI.\nTo jest nowy typ kursu, których w przyszłości będzie więcej. Są to treściwe kursy zorientowane na praktyczne umiejętności w danym temacie.\nW ramach prapremiery wszyscy moi dotychczasowi subskrybenci newslettera będą mogli kupić go po najniższej cenie 295zł brutto.\nSkorzystaj z tego linka - ważny jest tylko do końca dnia.\nObecnie nikt spoza moich subskrybentów o nim nie wie i już wkrótce ujawnię go innym i udostępnie kurs już po wyższej cenie.\nAI prompts:\nJesteś twórcą treści i wysyłasz newsletter twoim odbiorcom.\nPrzygotuj streszczenie z transkrypcji nagranego wideo. Wybierz z niego podsumowanie części dopasowanych do tych nagłówków paragrafów:\nDlaczego nie możesz już ignorować AI\nCo mnie osobiście przekonało\nWciąż będzie mnóstwo pracy wokoło LLM\nTa jedna rzecz, w której AI nas nie zastąpi to…\nOto transkrypt z wideo:\n","tags":["newsletter","ai","devops"],"title":"Newsletter #116 - Tak AI wpłynie na naszą branżę"},{"categories":["newsletter"],"date":"November 19, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/115/","section":"newsletter-archive","summary":"A zatem wracam po pewnej przerwie. Ta wynikła z konieczności uporządkowania pewnych rzeczy.\nCzasem potrzebujemy się zatrzymać, przemyśleć pewne sprawy i spojrzeć na to co robimy, gdzie jesteśmy z innej perspektywy. I tak właśnie zrobiłem.\nNie będę Cię tu zanudzał osobistymi szczegółami, ale najważniejsze to to, że nie mogłem usiedzieć w miejscu do tego stopnia, że przypadkiem wydałem nowy kurs (szczegóły poniżej).\nW międzyczasie wydałem trzecią edycję kursu Kubernetes po polsku z nowymi materiałami dotyczącymi bezpieczeństwa.\nDo tego poprowadziłem ciekawe szkolenie Zhackuj Kubernetesa, które spowodowało popłoch w niektórych organizacjach i uświadomiło jak niebezpieczne są domyślne konfiguracje.\nTo nie koniec i mam sporo planów na najbliższą i tą dalszą przyszłość.\nPlany\nWkrótce powrócę z ciekawymi treściami wideo, gdyż mam przygotowaną już listę tematów. Myślę, że będą one ciekawe dla wielu osób, gdyż poza rzeczami technicznymi poruszę również aspekty strategii i koncepcji dla tych bardziej doświadczonych.\nBędzie też o AI w kontekście wykorzystania narzędzi i modeli w pracy z platformami oraz aplikacjami. Od tego nie uciekniemy, a szczególnie teraz gdy już są naprawdę ciekawe i dojrzałe narzędzia.\nUtworzę też więcej kursów. Będzie trochę kursów bardziej praktycznych, krótszych (ale wciąż treściwych!) i co najmniej jeden duży, unikalny w treści i bardziej rozbudowany z omówieniem złożonych koncepcji.\nJuż się nie mogę doczekać - tworzenie takich treści przynosi mi olbrzymią satysfakcję i z tego co słyszę przynosi również korzyści moim kursantom.\nWznowię newsletter czego pierwszą oznaką jest niniejszy mail. Nie wiem jeszcze czy będzie on co tydzień, ale będę go wysyłał regularnie. Przemyślałem jakie treści będę chciał w nim umieszczać i sądzę, że zainteresują one wiele osób szukających czegoś więcej niż listę linków do poczytania.\nW przyszłym roku planuję pojawić się na kilku konferencjach i meetupach. Będę wysyłał informacje jak tylko otrzymam potwierdzenie występu.\nBardzo pozytywnie odbieram spotkania na żywo. Okazuje się, że introwertycy tacy jak ja jednak potrzebują spotkać się od czasu w realu.\n🎉 Prapremiera kurs SkillBooster GitLab CI\nStało się to niemalże przypadkiem. Nie mogłem usiedzieć w miejscu i coś mnie naszło, aby zerknąć bardziej szczegółowo na GitLab CI. I tak narodził się nowy kurs, który właśnie opublikowałem - SkillBooster GitLab CI.\nTo jest nowy typ kursu, których w przyszłości będzie więcej. Są to treściwe kursy zorientowane na praktyczne umiejętności w danym temacie.\nJako pierwszy wypuszczam kurs o GitLab CI, bo wiem, że jest on bardzo popularny. Ja w moim kursie omawiam go od praktycznej strony potoków CI/CD, które budują obrazy kontenerów i wdrażają aplikacje na Kubernetesa.\nDowiesz się też z niego jak postawić własną instancję oraz zrozumiesz jak to wszystko działa pod spodem.\nWięcej szczegółów dowiesz się na tej ukrytej stronie kursu.\nI teraz najważniejsze. Jesteś pierwszą osobą, która się o tym dowiaduje, bo kurs jest niedostępny póki co dla innych.\nPostanowiłem, że w ramach prapremiery wszyscy moi dotychczasowi subskrybenci newslettera będą mogli kupić go po najniższej cenie 295pln brutto.\nWystarczy, że skorzystasz z tego linka. Promocja trwa tylko 7 dni (do 28 listopada). Później udostępniam kurs publicznie dla innych już po wyższej cenie.\nZapraszam na spotkanie Cloud Native Warsaw\nJeśli jesteś z Warszawy lub będziesz w stolicy 28 listopada to wpadnij na pierwszy spotkanie społeczności Cloud Native Warsaw.\nKiedyś już prowadziłem podobną grupę w ramach meetupu, a teraz wracam z tą inicjatywą i zapraszam Cię na to spotkanie.\nBędę tam ja jako współorganizator, będą też inni entuzjaści technologii Cloud Native, będzie pizza i okazja do pogadania.\nLiczba miejsc ograniczona więc jeśli masz ochotę to zarejestruj się już teraz na oficjalnej stronie spotkania.\n","tags":["newsletter","rozwoj","osobiste"],"title":"Newsletter #115 - Wracam"},{"categories":["learning"],"date":"October 2, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/learning/kurs-kubernetes-po-polsku/","section":"learning","summary":"","tags":["kubernetes","kurs","pro"],"title":"(PL) Kurs Kubernetes po polsku"},{"categories":["learning","webinar"],"date":"September 8, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/learning/zhackuj-kubernetesa/","section":"learning","summary":"","tags":["kubernetes","security","learning"],"title":"(PL) Zhackuj Kubernetesa"},{"categories":["articles"],"date":"August 5, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/top-10-tips-for-kubernetes-certification/","section":"articles","summary":"In my previous article, I wrote about Kubernetes certifications and my impressions of them. This time, I\u0026rsquo;m going to share 10 helpful tips for those who are considering taking any or all of the exams.\nSo let’s cut to the chase.\n1. Use techniques to speed up the work It\u0026rsquo;s number one for obvious reasons. It\u0026rsquo;s fundamental to be as fast as possible during the exam, as the exam\u0026rsquo;s tasks test your actual skills, not your knowledge of Kubernetes. The latter is a requirement, but not sufficient to pass.\nTrust me, you can be Kubernetes guru, but if you haven’t practiced enough or you’re just too slow you may fail.\nSo here’s the most important things I encourage you to learn and use during the exam:\nKubectl autocompletion - I’ve been using it for many years now and I just can’t imagine working with any Kubernetes cluster without this feature. Of course, I wish there were k9s available during the exam, but autocompletion can still save you some precious time. Kubectl create - In many cases creating an object from scratch is just far easier and faster with kubectl and its vast (but not all) resources you can create. And even if it’s not flexible enough, you can always use it to quickly create a skeleton for your object (use the dry run flags with the yaml output: ‘ --dry-run -o yaml’). I especially like to create RBAC roles and bindings, because all the options are there without having to write a single line of yaml. Use different methods for getting information about the resources - What I mean by that is that you learn to retrieve and filter data from the Kubernetes API. You need to know how to efficiently filter the stream of enormous information about a set of objects.\nSo your job is to know the yaml output ( -o yaml) and how to find the requested data by using grep or dedicated tools such as yq. Sometimes json is the way to go with the jq command for filtering or the ‘jsonpath’ output with its builtin filtering mechanism.\nI also find the ‘ custom-columns’ output option to be particularly handy and fast in some cases. Bash shortcuts - Another way to increase your speed is by leveraging Bash’s readline library integration. This allows you to significantly shorten the time you spend on typing the commands, searching them from history and modifying them. Here’s my favorite and yet not so obvious shortcuts: Search history incrementally ( ctrl+r) Move between words ( alt+arrows) Delete words ( alt+backspace) Delete whole parts of line ( ctrl+k, ctrl+u) Edit in place - I know that for some of us GitOps is the only way to apply changes in the cluster, but in the exam you do it manually and instead of changing the manifest it’s faster to just ‘ kubectl edit’ it. And yes - vim is your best friend here. 2. Use labs When you buy a Kubernetes exam, you are entitled to use a lab provided for free that you can use to practice your exam. Don’t skip it for at least two reasons.\nFirst, it shows you the environment you will use during the exam. You cannot use your tools on your laptop - you’re provided with a set of tools within a controlled environment.\nWhat made it less convenient and something I had to get used to were the keyboard shortcuts. Learn how to copy and paste, because you’re going to use it a lot and you better do it as fast as possible. The same applies to searching through the documentation - it’s the most valuable resource available during the exam and as long as you haven’t memorized all the options, you’re going to copy\u0026amp;paste it a lot.\nSecond is of course the tasks. They are supposed to be harder than the real tasks on the exam and it’s true for all of them except for CKS. At least in my case I was able to complete all of the tasks in the simulation without any problem. However, the tasks on my exam were a bit harder. Maybe it’s just bad luck, but still I wouldn’t recommend taking any Kubernetes exam without using the provided lab first.\n3. Learn to find information in official documentation As I already mentioned, the most important resource you have during the exam is the official Kubernetes documentation.\nLearn the structure of it to efficiently find the information you need. There are different types of documents there - some give a quick overview of a specific concept, and some contain many examples. You need the latter ones because there’s no time or need to learn the concepts.\nI often use the official documentation to learn about specifics of the resource I need to use, but I’ve found that during the exam the faster option is to use the ‘ kubectl explain’ command. It’s easier to copy the found option into your manifest.\nLearn how to use it and you’ll save yourself some time.\n4. Use vim I didn’t check if there are other editors available in the exam’s environment for one simple reason - when I work in the console I use vim/vi. I highly recommend learning it if you haven’t done so already.\nIf it’s not your daily editor (I use mostly VS code) then I recommend refreshing a few important shortcuts and commands:\nQuit with saving - Use shift+z+z which is faster than traditional ‘ :wq’. If not for speed then at least I would use it to provoke questions from intrigued colleagues ;) Delete whole line - dd Change whole line - cc Change word - cw Change the word under the cursor - caw Move to the top of the file - gg Move to the bottom of the file - shift+g Search the file - “ /” and then “ n” for the next occurence 5. Read very carefully When you are in the middle of passing an exam, you feel the pressure and often you may miss some important information. That’s why I recommend reading the task description carefully twice or even thrice.\nOnce, I found myself looking for information on the wrong Kubernetes component and after a bit of frustration growing in me (I couldn’t find the option required by the task), I read back the task content once again and found I lost a few minutes looking in the wrong place.\nI would also recommend reading the existing configuration files from top to bottom. They are yaml files and as you know the fields can be put in any order. Don’t expect the usual format with lexicographical order, like I did.\n6. Leave the hard tasks to the end I guess this is a general rule for any exam, but I\u0026rsquo;ll emphasize it anyway. During my CKS exam, I spent too much time on a particularly long and difficult task, naively expecting to be able to solve it with documentation or some experimentation, and this approach probably cost me my first failed attempt to pass CKS.\nRemember that you don’t need 100% points. to pass There are passing thresholds for each exam, and they are much lower but no one knows how many points are given for each task. It’s better to solve the easy ones first and then move on to the harder ones.\n7. Know NetworkPolicy really well This applies mostly to CKS and CKA. I find the NetworkPolicy resource a bit complex and that’s why, like most of the people, I use this editor to create netpol objects.\nHowever, this is not possible during the exams. You need to learn to create them from scratch. There is no helpful command for that like for RBAC, and so all you have to do is practice writing egress and ingress rules in various configurations.\n8. Know apiserver very well You’ve probably read that you need to learn the kube-apiserver component. And just like Ron Swanson, let me repeat that - you really need to learn it very, I mean VERY WELL.\nI cannot stress this enough. This component is crucial for Kubernetes and also for you as a potential, future certified export on it.\nYou need to know most of the options (its command line flags) and how to apply them. Because the exams are hands-on, you risk breaking your cluster if you misconfigure your kube-apiserver, so please remember to make backups of the config files.\n9. Practice backup and restore of etcd Funny thing about these Kubernetes exams is that they assume you’ve worked with the control plane servers or you’re going to. In fact, many organizations choose to use Kubernetes-as-a-Service rather than managing the control plane part. I get it - it’s much easier.\nHowever, from the exams perspective it doesn’t matter - you need to know how to operate control plane nodes.\nSo, if you haven’t worked with etcd and/or kubeadm, there might be a bit of work ahead of you to learn them, as it’s essential to know how to backup and properly restore your cluster.\n10. Implement all changes and then restart Last advice is purely technical. Restarting the services takes time (about 30-60 seconds), and if you do it multiple times, it can add up to a few precious minutes. And trust me if I repeat it once all over again - every minute counts.\nRead the instructions carefully, and if changes are required in one or more components of the control plane, save time by making all the changes once and then trigger restarts. Keep in mind that for static manifests, Kubelet monitors changes in those files and restarts the containers accordingly.\nConclusion Remember, you could be the most knowledgeable Kubernetes user/admin/architect and still fail the exam because of the environment, lack of time to learn along the way, or simply the way the tasks are presented.\nI hope you\u0026rsquo;ll find my tips helpful, and I wish you the best of luck on your Kubernetes certification journey!\n","tags":["certification","cka","ckad","cks","kubernetes","kubestronaut","learning"],"title":"Top 10 Tips for Kubernetes Certification"},{"categories":["articles"],"date":"July 29, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/how-to-get-certified-in-kubernetes-and-is-it-really-worth-it/","section":"articles","summary":"Some people say certificates and exams are not necessary for those who really know their stuff. I will address it later on but I want to start with sharing my experience on Kubernetes certification after I recently passed 5 exams and got awarded with the Kubestronaut title.\nI decided to share my thoughts and tips on the process to help anyone thinking of taking an official Kubernetes exam and getting a certificate.\nIf you\u0026rsquo;re looking for technical tips I will share them in the next article. I am also not going to describe particular exams’ content because I just can\u0026rsquo;t - I’ve explicitly promised that to the Linux Foundation by acknowledging at the beginning of each exam and I always keep my promises. Even if I did, it wouldn\u0026rsquo;t be much help as the exams are practical and require from users both theoretical knowledge and its very quick application to a live environment.\nOfficial certificates for Kubernetes practitioners There are 5 exams and official Kubernetes certificates available from the Linux Foundation.\nKCNA and KCSA are question-based exams that require theoretical, but surprisingly also practical, knowledge of Kubernetes. These are introductory exams, and in my opinion, they can be brute forced, especially for the practical skills that you might miss if you haven\u0026rsquo;t worked with a Kubernetes cluster.\nI wouldn\u0026rsquo;t say they are trivial though. I was surprised to find really interesting questions that made me investigate particular topics after my exams.\nI\u0026rsquo;m happy that KCSA includes best practices on security and the required knowledge in most cases isn\u0026rsquo;t tied to any specific solution or even a project.\nThen there are 3 practical exams: CKAD, CKA, and CKS. Let me share my impressions on who should consider taking them based on the type of tasks I have seen on my exams.\nLet\u0026rsquo;s start with CKAD. As the name suggests it is recommended for developers who work with Kubernetes environments. I totally agree and I think that this might be your first choice, regardless of your role.\nI find that exam the most generic one that verifies your skills on managing containerized applications on any Kubernetes-based platform.\nThe next is CKA. In my opinion it is mostly for DevOps or Ops guys. If you haven\u0026rsquo;t worked with the control plane part of a Kubernetes cluster, haven\u0026rsquo;t done any upgrades or haven’t set up a cluster from scratch using kubeadm then this might not be for you. It\u0026rsquo;s a bit harder than CKAD and requires more knowledge on Kubernetes internals, especially the aforementioned control plane components. In my opinion it requires proficiency in Linux as well, so that’s why I think it’s a bit harder and not for everyone.\nThe last one is CKS. Again, as the name suggests, it\u0026rsquo;s for people who are taking care of the security of platforms using Kubernetes and containers. Because of the content I suggest this exam to be considered as a mandatory addon to CKA.\nI would also recommend it for developers, but in my opinion some internals could be too overwhelming for those without much experience in Linux environments.\nSecurity is everyone\u0026rsquo;s job and because CKS requires Knowledge on securing and hardening your Kubernetes platform I strongly suggest at least one person in your organization has the knowledge required by the exam or the certification itself.\nI cannot imagine a production environment managed by a team without deep dive knowledge on at least RBAC and hardening the control plane components.\nHow I got my Kubestronaut title All the requirements are listed on the official site of the program. Like I mentioned before I had to sit and pass all the five exams.\nI\u0026rsquo;ve been providing Kubernetes training for the last 8 years and I\u0026rsquo;ve been helping various companies in the implementation of the Kubernetes or OpenShift in the environments. Based on my experience and to also challenge myself a bit, I decided to sit all 5 exams in 5 days.\nI scheduled both KCNA and KCSA exams for the same day as I thought they would be easy to pass and wouldn\u0026rsquo;t require too much effort from me.\nAnd indeed, I passed them quickly and moved on to my first practical exam - CKA. I chose it because it’s a prerequisite for the CKS exam and I couldn\u0026rsquo;t even schedule it without passing CKA first.\nAnd so I did. I didn\u0026rsquo;t prepare that much and it was a real fun getting my hands on the exam tasks.\nThe next day I sat the CKAD exam and it also went smoothly for me which made me think that the last exam wouldn’t be much of a challenge either. And oh boy, was I wrong!\nOn the last, fourth day I sat the famous CKS exam and that was something quite surprising for me. I cannot reveal any details other than the fact that I simply failed this exam - I was 2% short of passing.\nAnd so my ambitious, maybe even crazy plan fell apart. Because of the delay (results are sent in 24 hours which in my case was almost always at least 20 hours) I was able to schedule a retake two days after. Initially I wanted to take it on Sunday but then I thought it\u0026rsquo;s just a really stupid idea and I better get myself a proper break.\nSo finally I managed to pass the CKS exam on my second attempt with the average score above 90% of all the exams (excluding the failed one).\nWould I do it again? Of course! Sometimes you need to challenge yourself to focus and find that motivation you haven\u0026rsquo;t felt for a long time. And that was my case and as a learner I\u0026rsquo;m going to use that approach in the future for similar scenarios as well. Of course I will share my thoughts and experiences in the form of similar articles or posts on my social media to encourage others.\nWhich Kubernetes exam is the easiest to take Both KCNA and KCSA are quite easy, but they are the introductory level and question based. They are also not well recognized in the community and I guess it was an idea of the creators of the kubestronaut program to include them for a smooth start and some kind of encouragement.\nWhen it comes to “real” exams CKAD is the easiest one in my opinion. It\u0026rsquo;s not the trivial one of course, but if you\u0026rsquo;ve been working with Kubernetes for a year or so, with some practice you may take the exam and even pass it on the first attempt.\nWhich Kubernetes exam is the hardest to take CKS. Period. This one might really surprise you. At least it did in my case.\nEven if you take the simulation exam available on the killer.sh platform (provided free by the Linux Foundation when you purchase the exam), you may be surprised, as I was, to find that in this particular case, the real exam is actually harder than the simulation.\nBut hey - it\u0026rsquo;s a great opportunity to learn and be one of those who managed to tackle all the difficulties of the exam, as most would probably just stick with CKAD or CKA.\nMy perspective on taking all 5 exams and receiving the Kubestronaut title Let me start with my perspective, because for me, taking these exams brought me a lot of joy and excitement. I got it from the whole process of preparing, setting myself this crazy challenge, reviewing and improving my knowledge, but also from sharing my experience and giving my support to others.\nWith over 8 years of experience using and teaching Kubernetes, I have to admit that I thought I knew it all. Yes, this may sound like my ego needed a confrontation with reality, and that\u0026rsquo;s why I\u0026rsquo;m glad I failed my CKS. Maybe it wasn\u0026rsquo;t a wake-up call (after all I was 2% short from passing) but I found it a precious lesson I had to take and indeed I did.\nI took the opportunity to review some elements and specific components in more detail, and most importantly, I practiced more to be as fast as possible. More on the importance of this in my tips article.\nIf you want to join the Kubestronaut program like me, you get your own jacket with the logo on it, which probably isn\u0026rsquo;t the benefit that is comparable to other programs like MVP from Microsoft or AWS Hero from Amazon.\nI haven\u0026rsquo;t received my gift yet, but I already got a 50% discount on the next exams, and I can get a 25% discount (20% starting next year) on KubeCon and other events.\nSo if you decide to take all 5 exams don\u0026rsquo;t count for some exciting, tangible benefits. You probably want to do it for other reasons.\nIs it worth getting certified I have noticed there are generally two groups of people.\nThe first group thinks that certification is lame and redundant these days. They say that these certificates give you nothing and don\u0026rsquo;t really measure the knowledge or the skills of particular technology.\nThe second group believes that getting some certificate will automatically make you an expert, bump your salary and make others look up to you boosting your ego.\nAs always, the truth lies somewhere between. As a holder of many certificates I must admit that the value of a particular certificate depends on many factors.\nThe second group believes that getting some certificate will automatically make you an expert, bump your salary and make others look up to you boosting your ego.\nAs always, the truth lies somewhere between. As a holder of many certificates I must admit that the value of a particular certificate depends on many factors.\nThe most important are the following three:\nRecognition and credibility of the issuing authority - that’s why even the best certification program is worthless when created by unknown organization Demand for knowledge covered by the certification - no one cares if you get a certificate on a niche technology Difficulty level of the exams - does the exam really check the knowledge and confirms the skills Three factors of a successful certification program\nIn the case of the official Kubernetes certification program all of the above requirements are met and that’s why I believe It\u0026rsquo;s worth considering proving yourself and your knowledge with all or only a chosen certificate from the official Kubernetes certification program portfolio.\nSkills confirmation One of the major factors is the fact that getting an official Kubernetes certification really confirms your skills. It\u0026rsquo;s all because the three main exams are task based and you just can\u0026rsquo;t cheat on them. Even if you could, it is just hard because of the time restriction and the number of tasks you are given.\nDon\u0026rsquo;t let anyone tell you that passing any of these exams (especially CKS) is trivial, because it simply isn’t. You can prove your skills in many ways and sometimes certificates are the most universal way.\nAnd often those who are the loudest critics of certification are probably the most afraid of a potential failure that could destroy their carefully crafted image as an expert.\nBy taking an exam, and even failing it, as I did, you step into the proverbial ring and prove yourself against time, perhaps against your own fears, insecurities, and doubts. It\u0026rsquo;s one of those things that makes an expert, and you can\u0026rsquo;t just skip it.\nIncrease self-confidence You might take an exam to boost your self-confidence. We are all affected by imposter syndrome, and having a proof of your skills can help you deal with it. This might be an underappreciated benefit of the certification process and I believe many of the folks have been thinking about it because they want to get that confidence.\nAnd that\u0026rsquo;s okay. I remember getting my Red Hat certifications (I took at least 8 practical exams) a long, long time ago because I wasn\u0026rsquo;t confident in my skills. At the time, it helped me advance my career as a result of my increased confidence and other skills I had built on top of it. It was a rough path at times, but it allowed me to gain more skills compared to the requirements of the jobs I had.\nFind motivation That’s very important. I see many people struggling with motivation for learning new things. You probably know how important goals are and setting them helps you achieve more.\nA certificate can be that tangible result of your learning and overall progress. This can really boost your morale during the journey of learning, sometimes failing, doubts and times of crisis.\nI always recommend getting a certificate for those who don’t know what to learn. The role of certification is also to guide and show the most important parts of the technology or a product.\nAnd often, learning the parts specified by the exam will lead you through other dependent and related areas.\nSo certifications can be a really useful learning tool with a reward at the end. If used wisely, it can be a great motivator for many.\nConclusion When it comes to certifications, it\u0026rsquo;s important to remember that not all of them are worth pursuing, and Kubernetes certificates aren\u0026rsquo;t the easiest to get. However, the whole process of learning and practicing is very satisfying - especially after you receive the email confirming that you\u0026rsquo;ve passed the exam.\nRecently I got a survey request from the Kubernetes and Kubestronaut certification program manager with questions on whether the certificates help to get a job. I can\u0026rsquo;t say that they do, because the demand for skills is still quite high and you can certainly get hired without them, but I do believe that passing these exams (especially CKS) proves your skills and thorough understanding of Kubernetes.\nHaving them in your head prepares you even better for designing and managing efficient platforms for all kinds of workloads running on any kind of environment (on-prem, cloud, hybrid, IoT etc.).\nSo yes - I think it’s worth it if you want to verify your skills and learn even more about Kubernetes.\n","tags":["certification","cka","ckad","cks","kubernetes","kubestronaut","learning"],"title":"How to get certified in Kubernetes and is it really worth it?"},{"categories":["newsletter"],"date":"May 28, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/114/","section":"newsletter-archive","summary":"To 114 newsletter i postanowiłem się zatrzymać. Włączam pauzę i przynajmniej na jakiś okres zawieszam wysyłanie newsletterów.\nPotrzebuję czasu na przemyślenia co dalej, zajęcie się bardziej własnym zdrowiem i złapaniem oddechu.\nTemat jest grubszy i jeśli chcesz wiedzieć więcej to polecam Ci mój artykuł, w którym dokładniej opisuję przyczyny oraz dzielę się osobistymi przemyśleniami.\nPostanowiłem, że kolejny newsletter wyślę jak już zdecyduję co dalej lub jak będę miał Ci do przekazania jakieś ważne informacje (np. ciekawa treść, wydarzenie itp.).\nNad czym będę dalej pracować Najbliższy czas to dla mnie intensywne przygotowania do 9 egzaminów (słownie: dziewięciu), które wykupiłem niedawno od Linux Foundation (wszystkie od Kubernetes i kilka dodatkowych jak Argo CD, Istio, Cilium). Tak jak pisałem wcześniej robię to zarówno dla siebie, ale też chętnie podzielę się doświadczeniami z Tobą.\nWkrótce zatem zaczynam pracę nad aktualizacją treści kursu Kubernetes po polsku. Nowa edycja wyjdzie pewnie już po wakacjach.\nPodejmę też pewne kroki w stronę realizacji projektu Architekt DevOps. Tutaj osoby zainteresowane dostaną ode mnie niedługo dalsze informacje.\nCo do reszty to jeszcze nie wiem i dlatego wciskam pauzę.\nNie oznacza to, że znikam. Zatrzymuję się, aby zdecydować co dalej. Pewnie częściej będę teraz na LinkedIn, ale nie zapomnę o Tobie i innych, którzy chcą się dalej rozwijać.\nWrócę z nowymi pomysłami - obiecuję!\nankieta - pomoz mi podjac decyzje standarcowe o profilu (wiek, gdzie pracujesz) co bys kupil ode mnie nowy kurs - o deploymencie kompleksowowo + gitops nowy kurs - o sieciach nowy kurs - o MLops mentoring??i ","tags":["newsletter","osobiste"],"title":"Newsletter #114 - Pauza"},{"categories":["pl"],"date":"May 27, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/pl/jak-nie-zostalem-influencerem-devops/","section":"pl","summary":"Jak nie zostałem influencerem DevOps Od bardzo długiego czasu chciałem zrobić coś ze swoją wiedzą i doświadczeniem co miałoby większy wpływ. Stąd na początku roku 2022 podjąłem decyzję o pełnym skupieniu na rozwoju mojej marki Cloudowski i tworzeniu profesjonalnych kursów z tematyki DevOps.\nAle nie poszło to po mojej myśli, a dalej opisuję dlaczego.\nDlaczego próbowałem Od zawsze uwielbiałam się uczyć. I nie - nie byłem prymusem w szkole ani na studiach. Dawałem radę, ale jeśli coś uważałem za mało interesujące to po prostu nie potrafiłem się angażować.\nCo innego jeśli to było związane z “komputerami”. Tutaj moje neurony się zapalały i wciąż to tak działa. Jeśli jest coś co mnie interesuje to potrafię siedzieć naprawdę nie odrywając się od dokumentacji, sprawdzania, eksperymentowania i analizowania.\nDzięki temu udało mi się zdobyć sporo certyfikatów i poznać wiele technologii z szeroko rozumianego obszaru DevOps. Najpierw Linuks, później kontenery, w międzyczasie cloud, a później Kubernetes i OpenShift.\nProwadziłem (i wciąż czasem prowadzę) wciąż tradycyjne szkolenia, które przynosiły mi olbrzymią satysfakcję. Chciałem to przenieść na większą skalę i dać ludziom z polskiego IT treści, które łatwiej im pozwolą pójść do przodu.\nJedną z rzeczy, którą bardzo cenię jest rozwój i przez kursy chciałem też pomóc innym. Długo siedzę w technologii co pozwala mi spojrzeć szerzej na to jak to pod spodem działa, aby później łatwiej to tłumaczyć.\nDodatkowo interesuję się tym jak działa nasz umysł oraz jak dużo wysiłku trzeba włożyć, aby obejść jego wbudowane ograniczenia takie jak strach przed nowością i zmianą, racjonalizacje wszelkiego rodzaju i błędy/pułapki myślenia (mój “ulubiony” to najczęściej zauważalny błąd potwierdzenia - confirmation bias).\nMoże to miała być jakaś moja mała misja, dzięki której będę mógł realizować zarówno moje wbudowane cechy oraz potrzeby. Wymyśliłem sobie, że patrząc na to co potrafię, co mnie kręci i co mógłbym robić w dłuższej perspektywie, tworzenie ciekawych materiałów edukacyjnych z zakresu DevOps będzie właśnie tą rzeczą.\nI najważniejsza motywacja, z którą to wszystko rozpocząłem - nie chciałem żałować w przyszłości tego czego nie zrobiłem, a mogłem. A czy żałuję teraz? Raczej nie.\nDlaczego mi nie wyszło Ale co to oznacza, że mi nie wyszło? Przecież ktoś mógłby powiedzieć, że to za krótki okres i mogę próbować dalej. To jest bardziej złożone i o tym napiszę dalej w lekcjach jakie wyniosłem z tego doświadczenia.\nCo do przyczyn jakie mogę teraz określić to jedna rzuca się mi automatycznie. Zacząłem zdecydowanie za późno. Mam już pewne doświadczenie życiowe (eufemizm na “jestem już trochę stary”), ale mam swój bagaż, który nie pozwalał mi na wcześniejsze rozpoczęcie realizacji mojego planu.\nWciąż trzyma mnie myśl, że mogło to wyglądać zupełnie inaczej gdybym poszedł za ciosem w roku 2018, gdy opublikowałem jako pierwszy w Polsce zupełnie darmowy kurs “Kubernetes po polsku”. Trochę nieśmiało, ale jednak z pasją i zaangażowaniem tłumaczyłem jak działa Kubernetes. Gdybym tylko wtedy to rozwinął to historia potoczyłaby się inaczej. Ale nie rozwinąłem, bo nie byłem gotowy. Miałem wówczas w moim życiu inne kwestie to ogarnięcia, które wymagały uporządkowania i ogarnięcia. A tak Kubernetes jest już standardem, ci co mieli się nauczyć to się nauczyli, a kolejne technologie z działki DevOps już nie są tak popularne. Bywa, ale wciąż mi szkoda.\nDruga przyczyna to mały rynek. Tak, robiłem materiały po polsku, ale przez to adresowałem tylko potrzeby i specyfikę polskiego rynku IT. Tylko okazuje się chyba, że może być on za mały.\nJeśli przyjąć, że na 10 (może nawet 15) programistów przypada jedna osoba od DevOps to przy zgrubnych szacunkach istnienia na rynku 400 tysięcy programistów ludzi od DevOps jest około 30-40 tysięcy. Niby dużo? Jednak jak w każdej grupie zawodowej osób, które chcą się kształcić (i to za swoje pieniądze) jest kilka procent. Myślę, że dotarłem do dużej części takich osób, ale nie jest to duża grupa. A może nie dotarłem, a mógłbym gdybym lepiej wykorzystał social media.\nTo kolejna przyczyna związana bardziej z moją naturą. Nie jestem i nie chcę być osobą kontrowersyjną. Nie lubię wdawać się w bezsensowne dyskusje, polaryzować i postować regularnie na konta w social media. Po prostu szkoda mi na to czasu. Poza tym mam ambiwalentny stosunek do social media. Karmią nasz perfekcjonizm (mój na pewno) i zabierają mnóstwo czasu, a czas to jest ta jedna rzecz, której mi najbardziej szkoda.\nLubię rzeczy praktyczne. Lubię technologię, ale wymyślanie ciekawych sposobów na to, aby zainteresować ludzi tym co to może im dać jest dla mnie osobiście nużące. Niestety, w dzisiejszym świecie nie pojedziesz daleko mówiąc o technologii zachęcając ludzi do rozwoju. Jeśli się nie wyróżniasz to jest ciężko. Tu muszę przyznać, że dużo leży po mojej stronie. Po prostu nie czuję się dobrze jako typowy influencer. To jak chodzenie w niewygodnych butach i powtarzaniu sobie, że może się jakoś rozchodzą.\nI ostatnia rzecz to fakt, że postawiłem wszystko na jedną kartę. Nie miałem innego, stałego zajęcia niż tego z przygotowaniem kursów, ebooków, webinarów, materiałów reklamowych, procesu sprzedaży i mnóstwem rzeczy naokoło. Owszem, prowadziłem też szkolenia stacjonarne, doradzałem firmom i miałem pomniejsze projekty. Większość jednak mojej aktywności to było zajmowaniem się moją podstawową działalnością.\nByć może, gdybym to robił na boku, obok standardowej pracy to wyszłoby inaczej. Może jednak rozciągnąłbym to tylko w czasie i doszedł do tych samych konkluzji.\nCzego się nauczyłem Wszystko jest lekcją. Z tym żyje mi się lepiej. Jako osoba zmagająca się z perfekcjonizmem stosowanie tego podejścia jest uwalniające. Stąd nie traktuję tego doświadczenia jako porażki. Nie jestem jakoś super wesoły z tego powodu, ale wyciągam lekcję i idę dalej. A oto jakie to lekcje dostałem.\nPotrafię być systematyczny i samodzielnie motywować się do pracy. Pisałem o tym w moim newsletterze już nie raz, ale odkryłem w sobie podwójną naturę - szefa analizującego co jest do zrobienia i zlecającego go do pracownika, który te zadania skrupulatnie wykonywał.\nSystematycznie wydawałem też newslettery. Z jedną, miesięczną przerwą, pisałem je tydzień w tydzień przez okres 2 lat i wysłałem ich do tej pory 114.\nBardzo pomaga mi śledzenie czasu z podziałem na kategorię. To jest podejście z wykorzystaniem celów behawioralnych. Nie wiem jakie będą rezultaty - ja mam po prostu zrobić to co jest do zrobienia. Dzięki temu mogę później analizować na co idzie mi najwięcej czasu, podjąć decyzję o zlecaniu części prac i lepszym planowaniu na przyszłość.\nTo jest ciekawa część, która mnie pozytywnie zaskoczyła. Korzystam z tego na co dzień pisząc również ten artykuł.\nOswoiłem się z ryzykiem. Nie uważałem się do tej pory za osobę odważną. Owszem, lubię i poszukuję zmian, ale określałem się raczej jako osoba stroniąca od ryzyka. A czymże było postanowienie o rzuceniu ciepłej posadki i zainwestowaniu mnóstwa czasu (i straconych okazji) jak nie ryzykiem?\nTo się przełożyło na inne aspekty mojego życia. Zacząłem szybciej (co nie oznacza krótko) podejmować decyzje akceptując, że ich konsekwencje mogą być różne. Takie życie. Kto nie ryzykuje nie je sernika! (nie pijam szampana i innych).\nZ technicznych aspektów to nauczyłem się dużo o obsłudze części marketingowej. Nie uznaję się jako osoba zaawansowana, ale umiem prowadzić własną kampanię reklamową i zarządzać automatyzacją listy mailingowej.\nDużą frajdę sprawiło mi nagrywanie podcastu. I choć teraz już sam go nie montuję, to przygotowywanie materiałów oraz rozmowa z gośćmi była nader satysfakcjonująca. Wyniki słuchalności nie są już jednak takie ekscytujące i stąd pomyślę co zrobię z tym dalej.\nPodobnie prowadzenie webinarów jest czymś co musiałem ogarnąć. Tutaj miałem więcej przygód, ponieważ nie ustrzegłem się wielu błędów (np. zmieniłem dostawcę usługi streamingu, który okazał się problematyczny). Zbudowałem jednak już podstawy do tego, aby kolejne webinary w przyszłości były lepsze. To wykorzystam z pewnością.\nPotwierdziłem też o sobie coś co wiedziałem już wcześniej. Bardzo potrzebuję urozmaicenia i dopływu nowości oraz zmian. To druga, ciemniejsza strona posiadania “Learnera” jako swojej silnej cechy/predyspozycji.\nSzkolenia o Kubernetes prowadzę od roku 2016 i wciąż tkwienie w tym obszarze najzwyczajniej zaczyna być odczuwalne dla tej strony mojej osobowości, która szuka nowości. Moje neurony, które zapalają się na dopływ nowej wiedzy zaczynają domagać się tego coraz bardziej.\nPrzedsprzedaż, kampanie reklamowe, obsługa mailingu, fakturowanie i inne powtarzalne elementy są monotonne, ale konieczne. Wypełniają one dużą część czasu, ale nie przyczyniają się do spodziewanych rezultatów.\nTo sprawia, że oczekiwana satysfakcja z sukcesu sprzedaży kursu i pomocy innym zostaje zastąpiona przez coraz większą frustrację. I postanowiłem, że tą potrzebą zdobycia nowych umiejętności zajmę się najbliższej przyszłości.\nNabrałem więcej pewności siebie. Wiem, że potrafię więcej niż kiedyś myślałem. Znoszę nawet hejterskie komentarze pod moimi treściami i potrafię je już lepiej ignorować.\nChwile zwątpienia i frustracji mnie nie zabiły. Nie wiem czy wzmocniły, ale nauczyłem się, że są to naturalne emocje. W ogóle myślę, że rozwój i praca to zarządzanie swoimi emocjami. To jest i będzie roller coaster. Musiałem się przyzwyczaić i to jest coś co będę dalej wykorzystywał.\nZadbanie o potrzeby Uświadomiłem sobie niedawno, że bardzo goniłem za jedną potrzebą udowodnienia sobie i innym, że mogę zrobić coś wyjątkowego. W tej pogoni zaniedbałem przez to inne moje potrzeby i przez to coraz mniej odczuwam zadowolenia z tego co robię.\nNależę do osób, które dużo czasu poświęcają na rozmyślaniu i autorefleksji. Dzięki temu znam moje mocne i słabe strony oraz mój portfel umiejętności. Na tej podstawie właśnie podjąłem decyzję o rozpoczęciu prac nad kursami i edukacji wśród polskiej społeczności DevOps.\nNiestety w międzyczasie coraz mniej adresowałem moje inne potrzeby takie jak własny rozwój. Ponownie zmierzyłem się z faktem, gdy mój wewnętrzny learner cierpi jak odtwarza tylko informacje i nie ma dopływu nowych, świeżych.\nTo budziło frustrację i nadszedł czas na zmiany. Jednocześnie zmieniają się potrzeby ludzi z branży i czuję, że mogę jeszcze wiele im dać, ale najlepiej jeśli połączę to z dbaniem o moje potrzeby ciągłego rozwoju.\nCo dalej Robię pauzę. Potrzebuję czasu na przemyślenia i realizację kilku projektów, które zacząłem.\nPrzede wszystkim czeka mnie aktualizacja mojego flagowego kursu “Kubernetes po polsku”, gdyż kolejna edycja będzie zawierała dodatkowe materiały przygotowujące do oficjalnej certyfikacji.\nWaham się co z podcastem i niewykluczone, że wciąż będę go nagrywał, bo przynosi mi to dużą satysfakcję.\nByć może wydam jeszcze jakiś kurs (lub kursy), ale muszę znaleźć najpierw interesujący dla moich odbiorców temat. No i może będzie on już po angielsku.\nTo co zmieniam już niedługo to język moich treści. W większości będą one po angielsku i będą bardziej wyspecjalizowane. Nie będę powielał tego co już łatwo da się znaleźć, a skupię się na bardziej zaawansowanych aspektach tworzenia platform opartych o Kubernetes/OpenShift.\nAI naprawdę nieźle namieszało i dlatego moje treści będą to uwzględniać. Więcej myślenia, projektowania i mniej technicznych niuansów. Tego pierwszego AI nie zastąpi - to drugie już to robi naprawdę dobrze.\n#MyślenieWciążWCenie #ZaweszeDoPrzodu\n","tags":["biznes","edukacja","rozwojosobisty"],"title":"Jak nie zostałem influencerem DevOps"},{"categories":["newsletter"],"date":"May 21, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/113/","section":"newsletter-archive","summary":"Kiedyś to były czasy! Pisali nawet w gazetach, że IT to niemalże dzisiejsza szlachta, która żyje sobie jak pączki w maśle. Rekruterzy dwoili się i troili, aby przyciągnąć kandydata, a Ci nawet umówieni na spotkanie rezygnowali w ostatniej chwili.\nTakich opowieści jest dużo, ale widać, że to już może być przeszłość i o tym dzisiaj napiszę więcej.\nStare, dobre czasy i dlaczego minęły Za obecny stan rzeczy należałoby obarczyć korporacje. To do nich się zaczęło. A w zasadzie od działań jakie musiały podjąć pod presją od inwestorów. Ci bowiem stracili cierpliwość i zaczęli domagać się (większych) zysków. Stąd ucięte zostały projekty, które nie przynosiły zysków lub potencjał na nie był zbyt daleki.\nZa tym przyszły zwolnienia i ruszyła lawina. Inne firmy mniejsze lub większe zaczęły postępować podobnie i taka sytuacja trwa do chwili obecnej. Firmy nie przyznają tego wprost, ale w kuluarach przyznają, że za zwolnienia może odpowiadać też rozwój AI - po prostu prostsze prace będą wykonane szybciej bez ingerencji ludzi.\nI tak jesteśmy w sytuacji, gdy jest już bardzo ciężko dostać pracę bez doświadczenia. Stanowisk juniorskich jest bardzo mało, a nawet jak się pojawiają to kandydatów jest bardzo dużo.\nA co z seniorami? Pewnie myślisz, że tacy nie muszą się martwić. Niestety w dużych organizacjach rządzą liczby i jeśli w tabelce pojawi się projekt do ucięcia to często lecą wszyscy bez względu na doświadczenie.\nTo ciągnie za sobą też stawki w dół, bo więcej jest osób na rynku poszukujących pracy. Ci co zmieniali pracę co kilka nawet miesięcy, aby dostać coraz to większe pensje zostają bez projektu (ich wysoka pensja staje się ciężarem dla firmy) i lądują na rynku pracy w nowych realiach poszukując już nowej ze zmniejszonymi stawkami.\nCzy dobre czasy jeszcze wrócą? Ciężko przewidywać. To zależy naprawdę od wielu czynników, a głównie od ludzi rozporządzających wielkimi pieniędzmi. Obecna sytuacja jest oczywiście trudniejsza, ale nie dla wszystkich.\nCi co mają “fach w głowie” nawet jak padną ofiarą zwolnień i cięć w projektach wylądują miękko w nowych firmach.\nTo co się dzieje obecnie może powodować pewien niepokój. A jak temu zaradzić? To proste - rozwijać umiejętności.\n“Łatwiej powiedzieć niż zrobić” pewnie pomyślisz. Fakt, możesz to potraktować radę podobną do tej jak jesteś smutny i ktoś przyjdzie mówiąc “To nie bądź i zajmij się czymś wesołym”.\nDla części takie czasy to może być motywacja, aby sprawdzić swoje umiejętności i ewentualnie nadrobić braki. Jak? Jedną z dróg może być certyfikacja.\nCertyfikacja Kubernetes - sprawdzę, abyś miał łatwiej Swego czasu zdobyłem kilkanaście certyfikatów branżowych o czym mówię w trzecim odcinku mojego podcastu. To dało mi motywację do nauki, ale też dużą dawkę pewności siebie.\nOstatnio brakuje mi wyzwań i skorzystałem z promocji (trwa do 21 maja) na egzaminy z Linux Foundation. Kupiłem pakiet 5 egzaminów i wkrótce zaczynam ich zdawanie.\nPo co? Chcę pomóc tym, którzy chcą zwiększyć poczucie pewności i bezpieczeństwa w tych dziwnych czasach. Przestrzegając zasad (nie będę mógł opowiedzieć o pytaniach) umieszczę dodatkowe informacje, które pomogą zdać egzaminy CKA, CKAD oraz CKS.\nKubernetes po polsku dla certyfikacji Postanowiłem, że kolejna edycja kursu “Kubernetes po polsku” będzie uzupełniona o materiały przygotowujące pod oficjalną certyfikację. Pomogę moim kursantom zdać te egzaminy przez wskazanie na najważniejsze elementy, na których skupiają się te egzaminy. Jestem przekonany, że duża część już tam jest, ale zmienię strukturę części materiałów i dostosuję go do tych wymogów.\n⏰ Tylko do dzisiaj (21 maja) do 21:00 możesz kupić kurs w pakiecie po starej cenie i uniknąć podwyżki, która będzie związana z aktualizacją kursu. Każdy kto ma dostęp do kursu ma również dostęp do jego przyszłych aktualizacji.\nPakiet dwóch części kupisz na stronie kursu.\n","tags":["newsletter","kariera"],"title":"Newsletter #113 - Czy to koniec z eldorado w IT?"},{"categories":["newsletter"],"date":"May 14, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/112/","section":"newsletter-archive","summary":"A kto powiedział, że za wszystko trzeba płacić (no, chyba, że chodzi o solidną wiedzę - o tym na końcu)? A co jeśli chcesz mieć wszystko u siebie i sobie to wszystko skalować, monitorować i wiedzieć gdzie lądują Twoje dane?\nObecnie wszystko możesz zbudować sam i często nie będzie to gorsze do tego co oferują wiodący producenci. Oczywiście jeśli masz odpowiednie umiejętności, czas i projekt, który tego użyje.\nMy Polacy od zawsze byliśmy “złotymi rączkami” i być może dlatego wśród nas jest tylu specjalistów, którzy budując własne rozwiązania zdobyli mnóstwo cennego doświadczenia.\nJa cenię sobie wciąż możliwość samodzielnego tworzenia kawałków platform. Wiem jednocześnie, że często duże organizacje będą wybierać produkty zamiast projektów open source dla swoich rozwiązań. I to jest też ok, bo wiesz co? Obecnie większość produktów jest i tak oparta o projekty open source. Dlatego warto wciąż eksperymentować i testować różne podejścia. Ja dzięki nauce Kubernetesa poznałem bardzo dobre produkt OpenShift i dzięki temu o wiele łatwiej jest mi z nim pracować.\nDlatego sprawdź moje nowe wideo, bo może znajdziesz tam inspirację do Twoich nowych rozwiązań i czegoś się nowego dowiesz.\nCebulowa automatyzacja Nagrałem nowe wideo, gdzie pokazuję jak totalnie za friko utworzyć własny automat budujący obrazy kontenerów. I nie tylko za friko, ale wykorzystujące niewielkie zasoby, aby można było to nawet uruchomić nie tylko na dowolnym Kubernetesie, ale nawet na Raspberry PI lub czymś równie niewielkim.\nWykorzystuję do rozwiązania projekt Gitea, który jest alternatywą dla GitLab czy GitHub. Polecam sprawdzić - może być to czysto hobbistycznie, ale być może ze względu na lekkość może ktoś tego również użyć do całkiem poważnych zastosowań.\nWideo jest do obejrzenia tutaj.\n⏰ Trwa sprzedaż kursów - pozostało kilka dni Nawet jeśli lubisz cebulowe rozwiązania, to niezbędne będą do tego solidne umiejętności.\nPrzypominam, że wciąż trwa przedsprzedaż kursu “Kontenery po polsku PRO”. Przy okazji uruchomiłem też sprzedaż kursu “Kubernetes po polsku” w atrakcyjnych pakietach.\nWarto sprawdzić teraz, bo kolejna taka okazja będzie dopiero za kilka miesięcy.\n","tags":["newsletter","gitea","cicd","koszty"],"title":"Newsletter #112 - Cebulowa automatyzacja"},{"categories":["ebooks"],"date":"May 9, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/ebooks/free-kubernetes-cluster/","section":"ebooks","summary":"","tags":["kubernetes","free","cluster","cloud"],"title":"Free Kubernetes Cluster in The Cloud"},{"categories":["newsletter"],"date":"May 7, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/111/","section":"newsletter-archive","summary":"Coraz częściej można spotkać tezę (nie tylko w memach), że nadchodzi koniec DevOps.\nCzy to prawda? Co jest przyczyną takich twierdzeń? Co przyniesie przyszłość?\nZapraszam na trochę dłuższy niż zwykle newsletter.\nZamieszanie z DevOps Od początku z DevOps było zamieszanie związane z definicją. Bo czym tak właściwie to jest?\nKultura? Stanowisko? Połączenie Dev i Ops, czyli co dokładnie?\nZacznijmy od stanowiska. Wciąż jest wielu ludzi, którzy powtarzają, że DevOps to nie stanowisko, a kultura. Ja też kiedyś byłem taką osobę. My swoje, a rynek swoje. Spójrz na oferty pracy - mnóstwo jest tam ofert dla inżynierów DevOps, a w organizacjach często określa się “ludzi od DevOps” jak tych zajmujących się… no właśnie czym dokładnie?\nAutomatyzacją? Czy ten kto automatyzuje jest automatycznie DevOps-em? I tak i nie. Bo możesz automatyzować procesy w fabryce produkującej samochody (tam też większość jest oparta o jakieś oprogramowanie) i czy wtedy możesz mówić, że “DevOpsujesz”? Ciężka sprawa.\nA może DevOps to nowe, modne określenie na adminów/ops-ów? Sam kiedyś zaczynałem jako taki admin (mówię o tym w drugim odcinku podcastu) i nie zgodzę się, że to to samo co obecnie DevOps.\nW końcu w worek DevOps wrzucane są nie tylko stanowiska, ale też produkty czego najlepszym przykładem jest Azure DevOps lub funkcja Auto DevOps w GitLab. Do tego Kanban, Scrum, Jira, CI/CD i mamy niezły kocioł.\nNa popularności DevOps wyrosły takie określenia jak DevSecOps (rozmawiam o tym w tym odcinku), MLOps i pewnie wkrótce może i AIOps.\nA jak w ogóle zostać takim DevOps? To też nie jest jasne, ale jeśli wciąż masz mętlik to polecam mój artykuł, gdzie opisuję najważniejsze umiejętności.\nNo i najważniejsza rozterka - czy DevOps to kultura? Niektórzy wręcz oburzają się na określanie tego w inny sposób. A jak jest w rzeczywistości?\nNarzędzia czy kultura Szacunek, wspieranie, słuchanie, blameless post-mortem, bezpieczeństwo w grupie (projekt Arystoteles w Google) i wiele innych rzeczy mówiących nam, że liczy się kultura i bez tego ani rusz.\nI znowu - i tak i nie. Nic nie jest proste jak już widzisz to z szerszej perspektywy i doświadczyłeś “wdrażania kultury DevOps”. Nie ma uniwersalnego przepisu na dobrą kulturę w organizacji - są tylko wskazówki i badania mówiące co działa.\nZawsze w zespole i w organizacji jest jakaś kultura. Co najwyżej może być toksyczna i uniemożliwiająca organizacji pójście do przodu.\nKażda organizacja to zbiór ludzi o różnym temperamencie, doświadczeniach i poglądach. Do tego wystarczy, aby liderzy organizacji mieli inny styl przywództwa i będzie to mieć olbrzymi wpływ na kulturę (głównie przez promowanie dobrych i zwalczanie złych zachowań).\nDołącz do tego uwarunkowania kulturowe kraju i dowiesz się, że taki “polski DevOps” to nie to samo co “brytyjski” lub “niemiecki DevOps” bowiem inaczej będzie przebiegać komunikacja, inny będzie stosunek do hierarchii itp.\nTo co jest według mnie to najważniejsze to, że kojarzenie DevOps z kulturą to błąd. Te wszystkie truizmy, wyświechtane frazesy może i dobrze wyglądają na prezentacjach dla menedżerów, podobają się paniom (i panom!) z HR oraz zarządowi, ale realnie wygląda to inaczej.\nJestem zdania, że kultura jest niezbędna, ale warto postawić na budowanie rozwiązań, a kulturę rozwijać w trakcie. Po drodze wyjdzie i tak, że wąskie gardła uniemożliwiające postęp nie będą technologiczne, a kulturowe i trzeba będzie je jakoś rozwiązać. To bardziej przypomina ewolucję i selekcję naturalną (również tą trudniejszą dotyczącą członków zespołu) niż gotowe przepisy.\nMy pracujący na co dzień z technologią lubimy konkrety i mamy dobry radar na bullshit. Chcemy tworzyć, usprawniać, naprawiać i dążyć do mistrzostwa przez automatyzację i dobór dobrych narzędzi.\nA to co warto budować to platformy.\nPlatform Engineering następcą DevOps? I na białym rumaku wjeżdża Platform Engineering, czyli konkrety nakierowane na rozwiązywanie problemów - tworzenie platform dla aplikacji i wszystkiego co jest potrzebne do ich działania.\nNie mówimy tu o tworzeniu kultury tylko budowaniu platform. To praktyki oparte o nowoczesne technologie (oczywiście kontenery, Kubernetes, projekty CNCF) dla różnych środowisk - tych na on-prem i na chmurze.\nWażniejsze obok narzędzi są jednak praktyki i taktyki. Z mojej perspektywy można traktować Platform Engineering jako wykorzystanie DevOps, Site Reliability Engineering, Cloud Native i wszystkiego czego dowiedzieliśmy się do tej pory do tworzenia platform dla aplikacji.\nA co z kulturą? Tu nie ma przepisów na ten element, bo jest już to oczywiste, że nie stworzysz dobrego rozwiązania bez szczerego feedbacku, dobrych post-mortem nakierowanych na usprawnienia i innych elementów. Po prostu skupiasz się na rozwijaniu platformy.\nTaka platforma (niektórzy określają ją jako Internal Developer Platform) ma służyć uruchamianiu mikroserwisów, monolitów (sic!), trenowaniu modeli dla AI oraz zapewnianiu wszystkiego co jest potrzebne wokoło.\nTak najkrócej - nie potrzebujemy Kubernetes, Cloud, GitOps tylko platform zbudowanych na tych lub innych technologiach. Na tym skupia się Platform Engineering właśnie.\n⏰ Szkolenie o kontenerach już w tą środę Już w tą środę 8 maja o godzinie 19:00 poprowadzę szkolenie online o tym jak łatwo tworzyć dobre obrazy kontenerów.\nMożesz jeszcze się zarejestrować tutaj.\n","tags":["newsletter","devops","platform-engineering"],"title":"Newsletter #111 - Czy to koniec DevOps?"},{"categories":null,"date":"April 26, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/27/","section":"podcast","summary":"W ramach tego odcinka spotkałem się z Piotrem, ekspertem z Isovalent, aby porozmawiać o fascynujących aspektach sieci, bezpieczeństwa i obserwowalności.\nPodczas tej inspirującej rozmowy zagłębiamy się w zalety wykorzystania CNI o nazwie Cilium, jednej z najbardziej innowacyjnych technologii sieciowych dostępnych na rynku\nPosłuchaj naszej rozmowy, aby dowiedzieć się:\nCo z sieciami i bezpieczeństwem ma wspólnego eBPF? Czym jest mikrosegmentacja? Jakie funkcje sprawiają, że Cilium jest tak atrakcyjny dla użytkowników? Jak 3 projekty firmy Isovalent (Cilium, Hubble i Tetragon) mogą pomóc we wdrożeniu observability? Czy Cilium proponuje rozwiązania multi-cluster i jakie są z tego realne korzyści? ","tags":["bezpieczeństwo","chmura","cloud","ebpf","kubernetes","observability","security","sieci"],"title":"27 - O sieciach, bezpieczeństwie i Cilium z Piotrem Jabłońskim"},{"categories":null,"date":"April 8, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/26/","section":"podcast","summary":"Moją przygodę z chmurą zaczynałem na AWS i podobni jak Łukasz zdobyłem wiele certyfikatów. Łukasz swoje zamiłowanie rozwinął dalej do tego stopnia, że zdobył uznanie Amazona i otrzymał tytuł AWS Community Hero.\nW naszej rozmowie skupiamy się na aspektach tej właśnie chmury.\nPosłuchaj nas, aby dowiedzieć się między innymi:\nCo daje Amazon swoich “bohaterom” ( AWS Heroes)? Czy zdobycie certyfikatów AWS jest trudne? Co zrobić, aby nie przepłacać za usługi w AWS? Czy faktycznie jeden dostawca chmury wystarczy? Dlaczego AWS ma dwie usługi dla kontenerów - ECS i EKS? Linki:\nProfil Łukasza na LinkedIn Strona Łukasza na AWS Community Heroes ","tags":["aws","certyfikaty","chmura","cloud","devops","eks","kubernetes","security"],"title":"26 - O największej chmurze publicznej (AWS) z Łukaszem Doroszem"},{"categories":["learning"],"date":"April 2, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/learning/kurs-kontenery-po-polsku/","section":"learning","summary":"","tags":["devops","docker","kurs"],"title":"(PL) Kurs Kontenery po polsku"},{"categories":["learning","webinar"],"date":"March 28, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/learning/opentelemetry-webinar/","section":"learning","summary":"","tags":["webinar","devops","kubernetes","cloud","opentelemetry"],"title":"Observability with Opentelemetry"},{"categories":null,"date":"March 25, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/25/","section":"podcast","summary":"Rozmowy o bezpieczeństwie nie muszą być nudne, szczególnie jeśli są ciekawi goście tacy jak Andrzej Dyjak.\nUsiedliśmy razem z Andrzejem i porozmawialiśmy o ciekawych tematach z obszaru bezpieczeństwa nowoczesnych platform dla aplikacji.\nPosłuchaj nas i dowiedz się między innymi:\nDlaczego w mniejszych firmach bezpieczeństwo często nie jest priorytetem? Na czym polegał jeden z najbardziej zuchwałych ataków ostatnich lat wykorzystujący podatności w procesie CI/CD? Czym jest OWASP Top 10? Jaka jedna metoda drastycznie zwiększa bezpieczeństwo? DevSecOps, DevSecOps i SecDevOps - jakie są różnice? Linki:\nOWASP Top 10 - https://owasp.org/www-project-top-ten/ OWASP Top 10 dla Kubernetes - https://owasp.org/www-project-kubernetes-top-ten/ OWASP Top 10 for LLMs (Language Learning Models) - https://llmtop10.com/ OWASP ASVS (Application Security Verification Standard) - https://owasp.org/www-project-application-security-verification-standard/ Cheat Sheet Series - https://cheatsheetseries.owasp.org/index.html The Consumer Authentication Strength Maturity Model (CASMM) - https://danielmiessler.com/p/casmm-consumer-authentication-security-maturity-model GDPR (General Data Protection Regulation) - https://gdpr.eu/ NIS (Dyrektywa o bezpieczeństwie sieci i systemów informatycznych) - https://digital-strategy.ec.europa.eu/en/policies/nis2-directive Data Breach Investigation Report - https://www.verizon.com/business/en-nl/resources/reports/dbir/ Bezpieczny Kod - https://bezpiecznykod.pl Automatyzacja Bezpieczeństwa w CICD: DevSecOps (ABCD) - https://abcdevsecops.pl Ofensywne Testowanie Web Aplikacji (OTWA) - https://ofensywnetestowanie.pl ","tags":["bezpieczeństwo","cicd","devops","devsecops","owasp","security"],"title":"25 - O bezpieczeństwie, DevSecOps i SecDevOps z Andrzejem Dyjakiem"},{"categories":null,"date":"March 11, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/24/","section":"podcast","summary":"Gościem tego odcinka jest Wojtek Barczyński, który jest VP of Engineering w polskim startupie Spacelift.\nObaj z Wojtkiem lubimy technologie z zakresu Platform Engineeringu i dlatego przedmiotem naszej rozmowy był Terraform, Kubernetes, wyższość Go nad Python, ale też “doświadczeni życiowo” (eufemizm na nasze PESELe) poruszyliśmy trudniejsze tematy pozatechnologiczne.\nPosłuchaj tego odcinka, aby dowiedzieć się między innymi:\nJaka jest przyszłość Terraforma Dlaczego Terraform można użyć do nauki chmury Czy AI może napisać cały kod do infrastruktury Kiedy lepszy jest Go, a kiedy Python Jak przygotować się do roli team leada Po czym poznać dobrego menedżera w IT Linki do odcinka:\nAtlantis Black - linter do pythona The Manager’s Path - polecana książka Radical Candor - kolejna ciekawa pozycja Profil Wojtka na Linkedin Podcastu możesz posłuchać na najpopularniejszych platformach.\nDodatkowo możesz go wysłuchać na stronie Google Podcasts (ma całkiem dobry odtwarzacz).\nDodatkowo odcinki publikuję również na YouTube.\n","tags":["devops","gitops","kariera","kubernetes","opentofu","platformengineering","teamlead","terraform"],"title":"24 - O ścieżce inżyniera i lidera zespołu od budowania platform z Wojtkiem Barczyńskim"},{"categories":null,"date":"February 26, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/23/","section":"podcast","summary":"Możesz chodzić na konferencje, czytać dokumentacje i snuć plany, ale dopiero praktyczne użycie rozwiązań usprawniających wdrożenia aplikacji pozwala na potwierdzenie realnej przydatności nowych technologii.\nI o tym rozmawiam z moim gościem tego odcinka - Mariuszem Pełką z P4 (operatora sieci Play). Nie ukrywam, że znam Mariusza z projektu, gdzie współpracowaliśmy nad budową platformy opartej na kontenerach, Kubernetes (a właściwie to OpenShift) oraz praktykach Platform Engineeringu.\nNasza rozmowa to wspaniała okazja do zaczerpnięcia doświadczeń z pracy z naprawdę dużym i złożonym środowiskiem.\nPosłuchaj nas i dowiedz się między innymi:\nDlaczego narastała frustracja w zespołach przy wdrożeniach nowych wersji aplikacji w czasach przed kontenerami i co się zmieniło po? Jak się sprawuje OpenShift w dużym środowisku? Jak niedopasowany do wymagań dużego środowiska okazał się jeden z popularnych projektów open source i czym został zastąpiony? Czy łatwo jest zrezygnować z Jenkinsa do budowania i wdrażania? Czym są Buildpacki i dlaczego są tak przydatne w dużym środowisku? Jak migrować do GitOps przy tak wielu aplikacjach i zespołach? ","tags":["argocd","buildpacks","devops","gitops","jenkins","kubernetes","openshift","platformengineering"],"title":"23 - O praktycznym podejściu do Platform Engineeringu na dużym środowisku z Mariuszem Pełką"},{"categories":["pl"],"date":"February 20, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/pl/dlaczego-utworzylem-bezplatny-kurs-kontenery-po-polsku/","section":"pl","summary":"W końcu mogę to ogłosić - właśnie publikuję mój nowy kurs “Kontenery po polsku” 🎉\nTo kolejny po “Kubernetes po polsku” kurs wideo, ale tym razem zupełnie bezpłatny.\nJest to kurs dostępny online dla wszystkich, którzy chcą porządnie poznać kontenery. Specjalnie kurs nazwałem “Kontenery po polsku”, a nie “Docker po polsku”, ponieważ mój kurs pomaga zrozumieć koncepty działania i wykorzystywania kontenerów.\nSkłada się on z wielu lekcji i postanowiłem, że będę je publikować co tydzień w dwóch formach:\nLekcje - sesje, na których opowiadam i pokazuję nas diagramach koncepty działania Laby - sesje, gdzie pokazuję praktyczne zastosowanie kontenerów i konceptów omawianych podczas lekcji Dlaczego podział na koncepty i laby Uważam, że koncepty powinny trafić do szerszego grona ludzi w IT, którzy nie potrzebują wiedzieć jak konkretnie używać tej technologii, ale powinni znać zasady działania.\nTo może się przydać architektom (np. tym, którzy już nie programują), menedżerom projektów, product ownerów i innym osobom, aby mogły swobodnie rozmawiać o technologii z praktykami.\nKoncepty są uzupełnione praktycznymi labami, które pozwalają na zbudowanie praktycznych umiejętności. Tą część polecam szczególnie dla programistów, testerów i inżynierów platform (DevOps).\nZaczynam od podstaw, ale moje materiały poruszają też bardziej zaawansowane techniki. Część z nich umieściłem, aby pomóc lepiej zrozumieć działanie kontenerów oraz pokazać narzędzia również dla tych co pracują już jakiś czas z Dockerem.\nDlaczego powstał Powodów jest kilka, a oto najważniejsze z nich:\n1. Mnóstwo kiepskich materiałów Jako osoba, która z kontenerami pracuje już od ponad 9 lat ciężko mi patrzeć na materiały dostępne w sieci. Mówię tu o zarówno prostych tutorialach oraz płatnych kursach.\nI doceniam pracę innych pasjonatów starających się uczyć, ale płatne materiały poruszające ten fundamentalny dzisiaj temat “po łebkach” to jest dramat.\nMoją odpowiedzią jest mój bezpłatny kurs, który przygotowałem tak jak wszystkie moje materiały, czyli prosto, przejrzyście i treściwie.\n2. Kontenery to wiedza fundamentalna Jeśli jesteś (lub chcesz zostać):\nProgramistą Inżynierem platform / DevOps Inżynierem QA / testerem To musisz rozumieć i potrafić efektywnie korzystać z kontenerów.\nOczywiście, że możesz się bez kontenerów obyć, ale prędzej czy później na nie trafisz, bo one drastycznie przyspieszają i upraszczają pracę przy projektach.\n3. Budowanie profesjonalnych umiejętności w IT w Polsce Chcę wnieść małą cegiełkę do budowy profesjonalnej kadry IT w Polsce. Ci co podjęli decyzję o rozwoju swoich umiejętności będą mieli dzięki mojemu kursowi łatwiejszą drogę.\nZamiast marnować czas na kiepskie tutoriale oszczędzą mnóstwo czasu i zbudują porządne fundamenty, które będą procentować w ich dalszej karierze.\n4. Osobista pasja do uczenia się i innych Odkąd zrozumiałem, że moją pasję do pochłaniania wiedzy mogę wykorzystać do jej priostego przekazywania innym, większość mojej energii przeznaczam na tworzenie materiałów takich jak ten kurs.\nCieszę się, że wciąż są odbiorcy na wiedzę przekazywaną w ten sposób, a mój kurs jest kolejnym i nie ostatnim w moim portfolio.\n5. Kubernetes Ucząc o Kubernetesie przez tyle lat zauważyłem jak wiele osób gubi się i ma pod górkę w zrozumieniu oraz używaniu go. To dlatego, że pominęli lub nie do końca ogarnęli wiedzę o kontenerach.\nKubernetes jest zbudowany na kontenerach i czerpie z koncepcji, którą zapoczątkował Docker. Prostota, niezmienialność (immutability), efemeryczność i wiele innych pomysłów Kubernetes implementuje na większą skalę.\nTo jednocześnie brakujący element w moich materiałach i dlatego postanowiłem udostępnić ten kurs.\nGdzie go obejrzeć Pierwsze odcinki kursu są dostępny na YouTube, a kolejne będą się pojawiać co tydzień. Pracuję też nad stroną kursu, gdzie będą dodatkowe materiały.\nTymczasem obejrzyj już pierwszą lekcję, bo tam prosto wyjaśniam czym tak naprawdę są te kontenery!\n","tags":["cloud","containers","devops","docker","edukacja","kubernetes"],"title":"Premiera kursu “Kontenery po polsku”"},{"categories":["learning"],"date":"February 13, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/learning/devops-self-study/","section":"learning","summary":"","tags":["devops","kubernetes","cloud","learning"],"title":"Self-study DevOps Projects"},{"categories":null,"date":"February 12, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/22/","section":"podcast","summary":"Z moim gościem, Tomaszem Mikołajkiem, łączy nas jeden kurs, który obaj w przeszłości przeszliśmy.\nChodzi o kurs o sieciach Cisco Network Academy. U mnie ta wiedza wciąż procentuje przy projektowaniu platform, a drugiego Tomka zaprowadziło to dalej do zgłębiania obszaru sieciowego.\nPosłuchaj naszej rozmowy, aby dowiedzieć się między innymi:\nDlaczego wciąż używamy IPv4 zamiast lepszego IPv6? Jak firmy zarabiają na sprzedaży adresów IP? Czym jest BGP i dlaczego jest “wołem roboczym internetu”? Jak łatwo popsuć internet wykorzystując wady BGP? Jak obronić się przed DDoS? Blog Tomka: https://showroute.pl/\n","tags":["bgp","internet","sieci"],"title":"22 - O protokole, na którym stoi cały Internet z Tomaszem Mikołajkiem"},{"categories":["learning","webinar"],"date":"February 8, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/learning/kubernetes-troubleshooting-webinar/","section":"learning","summary":"","tags":["kubernetes","troubleshooting","webinar"],"title":"(PL) Kubernetes Troubleshooting"},{"categories":["newsletter"],"date":"January 30, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/97/","section":"newsletter-archive","summary":"Dzieje się. Nowy odcinek podcastu, szkolenie, a dodatkowo w tym tygodniu wypuszczę dość nietypowe treści. Pojawią się one na moich kanałach social media i sam jestem ciekawy jak zostaną one odebrane.\nTo już 97 newsletter (!), a ja przygotowuję niespodziankę na setne wydanie. Jeśli masz jakieś pomysły to odpisz na tego maila i się podziel ze mną.\nNowy odcinek podcastu - rozmowa o słowie na K Gościem tego odcinka jest Tomasz Madej, który w Accenture zajmuje się chmurą w ramach praktyki Cloud First.\nOd programisty do menedżera - to ciekawa ścieżka i tym razem obok tematów technicznych rozmawiamy o jeszcze ważniejszym i trudniejszym.\nKomunikacja. Nie tylko w rozumieniu sieci, ale głównie o tym jak ważna jest do budowy zespołu oraz do zrozumienia potrzeb i dostarczania wartości klientom.\nPosłuchaj tego odcinka, aby dowiedzieć się między innymi:\nDlaczego warto mieć przeszkody w karierze i w czym one pomagają? Dlaczego organizacje już nie tak chętnie zatrudniają juniorów? Co przynosi region Azure w Polsce i czy warto już z niego korzystać? Kiedy i dlaczego firmy zostają przy swoich serwerowniach zamiast w całości migrować do chmury? Dlaczego bez sprawnej komunikacji nie zbudujesz dobrego zespołu cloud ani biznesu? Na czym powinni się skupiać konsultanci w czasach wszechogarniającego AI? Podcast “Rozchmurzony” dostępny na wszystkich popularnych platformach do ich słuchania oraz na stronie odcinka.\nWpadnij na moje szkolenie w ten czwartek Przypominam, że w ten czwartek o 19:00 prowadzę bardzo ciekawe szkolenie online o diagnozowaniu problemów na Kubernetesie.\nZarejestruj się na stronie wydarzenia i przy okazji odbierz mój przewodnik - szczegóły na stronie.\nAha - podczas tego szkolenia odbędzie się też oficjalna premiera nowej edycji kursu Kubernetes po polsku 🙂\nCloudowski patronem medialnym konferencji! Zostałem patronem medialnym konferencji CodeFrenzy i choć sam na niej nie wystąpię to wydaje się ciekawa.\nJa zamierzam wystąpić na tegorocznej edycji 4developers i pewnie kilku innych - dam znać jeśli będziesz chcieć przybić piątkę.\nPóki co poniżej oficjalne informacje od organizatora.\nW dniach 5-8 lutego 2024 odbędzie się CodeFrenzy, wirtualna konferencja poświęcona najnowszym trendom i innowacjom w świecie programowania. Wydarzenie zrzesza pasjonatów technologii, oferując im wyjątkową okazję do zdobycia aktualnej wiedzy oraz spojrzenia na branżę IT z nowej perspektywy.\nCo w programie?\nInspirujące prezentacje: na wirtualnej scenie wystąpią prelegenci znani z konferencji: PLNOG, Oh My H@ck, CONFidence, 4Developers oraz JDD. Najgorętsze tematy, w tym: architektura aplikacji, cyberbezpieczeństwo, rozwiązania sieciowe, uczenie maszynowe czy AI. Panel dyskusyjny: eksperci z Rad Programowych wspomnianych wydarzeń omówią szereg zagadnień z zakresu security/ICT i odpowiedzą na pytania. Networking: mimo formuły online, uczestnicy mają możliwość wymiany doświadczeń za pośrednictwem platformy Eventory. Konkursy: możliwość wygrania biletów na stacjonarne konferencje organizowane przez PROIDEA. Dostęp do nagrań po zakończeniu wydarzenia. Aby wziąć udział w wydarzeniu, konieczna jest bezpłatna rejestracja.\nWięcej informacji o agendzie oraz darmowe bilety można znaleźć na oficjalnej stronie wydarzenia: https://codefrenzy.pl/\n","tags":["konferencje","kubernetes","podcast","szkolenie"],"title":"Newsletter #97 - O słowie na K"},{"categories":null,"date":"January 29, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/21/","section":"podcast","summary":"Gościem tego odcinka jest Tomasz Madej, który w Accenture zajmuje się chmurą w ramach praktyki Cloud First.\nOd programisty do menedżera - to ciekawa ścieżka i tym razem obok tematów technicznych rozmawiamy o jeszcze ważniejszym i trudniejszym.\nKomunikacja. Nie tylko w rozumieniu sieci, ale głównie o tym jak ważna jest do budowy zespołu oraz do zrozumienia potrzeb i dostarczania wartości klientom.\nPosłuchaj tego odcinka, aby dowiedzieć się między innymi:\nDlaczego warto mieć przeszkody w karierze i w czym one pomagają? Dlaczego organizacje już nie tak chętnie zatrudniają juniorów? Co przynosi region Azure w Polsce i czy warto już z niego korzystać? Kiedy i dlaczego firmy zostają przy swoich serwerowniach zamiast w całości migrować do chmury? Dlaczego bez sprawnej komunikacji nie zbudujesz dobrego zespołu cloud ani biznesu? Na czym powinni się skupiać konsultanci w czasach wszechogarniającego AI? ","tags":["azure","biznes","cloud","komunikacja","onprem","praca"],"title":"21 - O kluczowym dla biznesu i zespołu słowie na K z Tomaszem Madejem"},{"categories":["newsletter"],"date":"January 23, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/96/","section":"newsletter-archive","summary":"Ja też chciałbym, aby coś raz uruchomione działało już zawsze. Do tej pory wiele technologii obiecywało, że tym razem już będziesz mieć spokój.\nŻadna jednak tego nie dowiozła. Z prozaicznego powodu - to po prostu niemożliwe. To jak sobie radzić? Zapraszam do szczegółów poniżej.\nPowody występowania problemów Tak jak najbezpieczniejsze systemy to takie odłączone od sieci tak samo stabilne systemy/aplikacje/platformy to takie, gdzie nie są wprowadzane zmiany.\nTo jest właśnie powód, dla którego tradycyjnie osoby zajmujące się środowiskiem (Ops, Admini czy też nawet DevOps) bardzo ostrożnie podchodzą do aktualizacji aplikacji. Fakt, każda zmiana to ryzyko i trzeba to będzie w pośpiechu naprawiać.\nAle nawet jak nie zostaną wprowadzone zmiany to i tak jest coś co możemy włożyć do worka “czynniki zewnętrzne”. To wszystko co jest poza naszą kontrolą czyli np.:\nawaria sprzętu przecięcie światłowodu przez koparkę pożar serwerowni awarii u dostawcy chmury atak DDoS Na takie ewentualności musimy być przygotowani projektując platformy i wdrażając aplikacje według zasad “Design For Failure”.\nDo tego praktyki inżynierii chaosu (chaos engineering) i powinniśmy przetrwać.\nA co z Kubernetesem? Nie miał on czasem ograniczyć liczbę takich przykrych niespodzianek?\nNajczęstsze problemy na Kubernetesie Na środowiskach pod kontrolą Kubernetesa jest już zdecydowanie lepiej niż bez. Istnieje dużo mechanizmów wspomagających zachowanie poprawnego działania systemów niwelujących skutki awarii czy różnych problemów. Są to między innymi:\nSondy (probes), w szczególności liveness Replikacja podów wraz z odtwarzaniem niesprawnych podów Mechanizm rozkładania podów po strefach dostępności i różnych węzłach Rozdzielenie warstwy wolumenów na dane przez niezależne wiązanie PV i PVC Monitorowanie stanu węzłów i mechanizm eksmisji podów Ale nie jest wciąż różowo i pozostają problemy, które się pojawiają i muszą być rozwiązywane indywidualnie. Zobaczmy jakie występują najczęściej.\nDziała, ale wolno **\n** Może aplikacja pożera zbyt dużo mocy obliczeniowej, może nowa wersja działa gorzej, może źle zostały przydzielone zasoby, może na węźle się coś dzieje dziwnego - powodów może być dużo, ale irytacja klientów końcowych zawsze jest.\nI to wyraźnie większa niż to gdy system nie działa w ogóle.\nPody nie wstają **\n** Aplikacje pięknie opakowane w obrazy kontenerów, pipeline wdrożeniowy zakończony sukcesem, a pody wstać nie chcą.\nCóż, też się zdarza. Czasem mechanizm kroczącej aktualizacji (rolling update) tu pomoże, a czasem wręcz przeszkodzi.\nA widziałeś status CrashLoopBackOff? To jest w ogóle ciekawa sprawa i niestety też często powodująca panikę w zespołach.\nDziwne zachowania podów **\n** Byłoby zbyt pięknie, gdyby pody działały wszędzie tak samo. Różnice będą zawsze - zaczynając od konfiguracji dostarczanej aplikacji przez inne węzły, inaczej działającą sieć poprzez skomplikowane przypadki, które pomimo małej skali (kilka podów) destabilizują środowisko.\nBłędy w komunikacji **\n** Taki Ingress jest fantastyczny dopóki nie psuje więcej niż ułatwia. Do tego wiele poziomów balansowania ruchu sprawia, że jest dużo punktów, gdzie coś może pójść nie tak.\nKomunikacja może być zbyt wolna, nie docierać w ogóle lub niepoprawnie rozkładać ruch po podach. Warstwy abstrakcji wówczas trzeba odsłonić i zajrzeć co jest pod spodem.\nPobierz mój przewodnik ze wskazówkami Jeśli masz dostęp do mojego kursu to umieściłem tam bardzo przydatny przewodnik z pomocnymi wskazówkami do diagnozowania i usuwania problemów, które najczęściej możesz spotkać na Kubernetesie.\nA jeśli nie masz dostępu do kursu to już wkrótce umożliwię jego pobranie również Tobie - po prostu pierwszeństwo mają moi kursanci 🙂\nPrzewodnik dostępny jest w ramach NOWEGO modułu 11 w części PRO.\n🤫 I tu UWAGA - mały spoiler **\n** Wkrótce odsłona drugiej edycji kursu z nowymi materiałami, które pomogą w diagnozowaniu i rozwiązywaniu problemów z aplikacjami i Kubernetesem. Będą one dostępne dla tych co zakupili kurs lub też zakupią.\n💥 Ogłaszam niniejszym oficjalnie, że PREMIERA nowej odsłony kursu odbędzie się 1 lutego, a wraz z nią też promocyjna sprzedaż dla tych co chcą rok 2024 rozpocząć z przytupem i wymasterować się solidnie z Kubernetesa.\nWięcej szczegółów już wkrótce…\n","tags":["eksperckieskille","kubernetes","kubernetespopolsku","troubleshooting"],"title":"Newsletter #96 - Jak szybko diagnozować problemy na klastrze"},{"categories":["newsletter"],"date":"January 16, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/95/","section":"newsletter-archive","summary":"Nagrałem kolejny odcinek podcastu. Jest to szczera rozmowa o Azure, a o szczegółach przeczytasz dalej.\nWykorzystam tą okazję do napisania o tym dlaczego warto być autentycznym w rozmowie, tak jak mój rozmówca Łukasz Kałużny.\nSzczerość popłaca To co odróżnia naszą kulturę od chociażby amerykańskiej jest fakt, że łatwiej nam przychodzi dawanie szczerej informacji zwrotnej (feedbacku). Jesteśmy po prostu szczerzy i jeśli uważamy, że coś nie działa jak powinno to mówimy to wprost, a nie owijamy w bawełnę jak Amerykanie.\nMoże niektórzy nie robią tego w dobry sposób, ale i tak jesteśmy doceniani za to. Dlaczego?\nBo to znacznie skraca ścieżkę dojścia do prawdy i przyczyn problemów. Eksperci jak my są cenieni za podawanie rzetelnych informacji, a nie politykę. Owszem, da się te dwie rzeczy połączyć i czasem warto. Nie warto natomiast rezygnować z autentyczności i szczerości.\nTo jest najlepsza droga do nauki, ale trzeba przegryźć czasem cierpkie słowa, które otrzymujemy w trakcie. Jeśli otrzymujemy komunikat powiedziany dobrze i szczerze to nie powinniśmy odbierać tego personalnie. Łatwo powiedzieć niż zrobić.\nWedług Raya Dalio i tego co napisał w Zasadach średnio zajmuje to 18 miesięcy, aby przyzwyczaić się do odbierania i dawania szczerych informacji.\nMyślę, że to jednak perspektywa Amerykanów nauczonych mówić, że jest wszystko dobrze nawet jak się pali. Dla nas Polaków to może być krótszy okres, ale trzeba trafić lub zbudować do tego odpowiednie środowisko.\nNowy odcinek podcastu Rozchmurzony Dobra rozmowa z Łukaszem Kałużnym, współprowadzącym podcast Patoarchitekci.\nStaraliśmy się tym razem utrzymać powagę, aby nie wykorzystać sarkazmu i ironii, którą tak obaj lubimy (jak chyba większość Polaków).\nŁukasz nie stronił od podzielenia się krytycznymi opiniami o Azure i podobnie jak w bezpośrednio rozmowie apeluję również tutaj:\nNIE ZABIERAJCIE mu przez naszą rozmowę zasłużonego tytuły Azure MVP 🙂\nPosłuchaj naszej szczerej rozmowy, aby dowiedzieć się między innymi:\nDlaczego pierwsza usługa oferowana na Azure nie wypaliła? Bez jakiej technologii nie warto pakować się obecnie w środowiska on-prem? Czy warto (według Łukasza) używać polskiego regionu Azure? Jak dobrze dawać “cierpki”, polskie feedback o produkcie/usłudze? Czy warto budować rozwiązania “cloud agnostic”? 🥐☕ Co zrobię jak nie będę mógł zapłacić za posiłek w restauracji? Podcast “Rozchmurzony” dostępny na wszystkich popularnych platformach do ich słuchania oraz na stronie odcinka.\n","tags":["azure","cloud","idp"],"title":"Newsletter #95 - Tak naprawdę szczerze o Azure"},{"categories":null,"date":"January 15, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/20/","section":"podcast","summary":"Dobra rozmowa z Łukaszem Kałużnym, współprowadzącym podcast Patoarchitekci.\nStaraliśmy się tym razem utrzymać powagę, aby nie wykorzystać sarkazmu i ironii, którą tak obaj lubimy (jak chyba większość Polaków).\nŁukasz nie stronił od podzielenia się krytycznymi opiniami o Azure i podobnie jak w bezpośrednio rozmowie apeluję również tutaj:\nNIE ZABIERAJCIE mu przez naszą rozmowę zasłużonego tytuły Azure MVP 🙂\nPosłuchaj naszej szczerej rozmowy, aby dowiedzieć się między innymi:\nDlaczego pierwsza usługa oferowana na Azure nie wypaliła? Bez jakiej technologii nie warto pakować się obecnie w środowiska on-prem? Czy warto (według Łukasza) używać polskiego regionu Azure? Jak dobrze dawać “cierpki”, polskie feedback o produkcie/usłudze? Czy warto budować rozwiązania “cloud agnostic”? 🥐☕ Co zrobię jak nie będę mógł zapłacić za posiłek w restauracji? ","tags":["azure","cloud","idp","kubernetes","onprem"],"title":"20 - Tak naprawdę szczerze o chmurze Azure z Łukaszem Kałużnym"},{"categories":["newsletter"],"date":"January 9, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/94/","section":"newsletter-archive","summary":"Może masz środowisko bardziej statyczne, gdzie się niewiele dzieje i Twój klaster chodzi sobie na tych samych węzłach od jego utworzenia.\nMoże jednak masz możliwość jego skalowania przez zarządzanie liczbą i typem węzłów. Nawet jeśli nie teraz to jeśli tylko Twoja organizacja dowie się o możliwości sporych oszczędności z tego wynikających to temat może znaleźć się “na tapecie”.\nTo jak to jest z węzłami kastra w Kubernetesie? Jak nimi lepiej zarządzać? To dzisiejszy temat newslettera.\nJakie są typy węzłów? Jeśli używasz Kubernetesa w chmurze jako usługi (EKS/AKS/GKE itp.) to sprawa jest prosta - możesz zarządzać tylko “zwykłymi” węzłami ( workerami).\nPrzy samodzielnie tworzonym klastrze masz jeszcze cały Control Plane do zarządzania. Węzły, które go tworzą są super, ale to naprawdę super krytyczne. Od ich wydajności i dostępności zależy praca całego klastra oraz aplikacji na nim chodzących.\nNa szczęście nawet dla dużych klastrów wystarczą trzy wydajne węzły. Rzadko stosuje się oddzielnie węzły na etcd i robi się to przy naprawdę dużych klastrach, aby podnieść poziom niezawodności całej platformy.\nWięcej mniejszych czy mniej większych? Najpierw Control Plane. Tu sprawa jest prosta - typ węzłów jest uzależniony od planowanej wielkości klastra. Ze względu na trochę złożony proces podmiany węzła Control Plane lepiej utworzyć je większe, aby uniknąć późniejszej operacji migracji.\nWęzły workery to już inna historia.\nZacznę od przypadku szczególnego, czyli jeśli aplikacje na klastrze niezbyt dobrze skalują się horyzontalnie. Wówczas lepiej dobrać maszyny o większej liczbie zasobów (głównie CPU).\nW pozostałych przypadkach reguła jest prosta:\nLepiej jest mieć więcej mniejszych węzłów niż mniej większych.\nDlaczego? Jest kilka powodów, a dwa najważniejsze z nich to:\nWiększa stabilność - w przypadku awarii węzła jeśli ma on uruchomionych mniej kontenerów i tym samym ich ponowne uruchomienie na innych węzłach będzie szybsze oraz mniej zauważalne. Podobnie w przypadku “kontrolowanych awarii”, czyli aktualizacji wersji klastra, gdy węzły również są niedostępne (np. w trybie rolling update). Większa wydajność - kontenery to procesy, które działają na wspólnym kernelu linuksowym. Ten owszem, ma mechanizmy do zapewnienia im prywatności (namespaces), ale są jego części współdzielone przez nie wszystkie. Takim ważnym jest pagecache, który pośredniczy w odczytywaniu i zapisywaniu danych na dysk. Przy większej liczbie procesów (czyli większej liczbie kontenerów uruchomionych na większym węźle) to może tworzyć wąskie gardło i zmniejszać wydajność. Tradycyjne autoskalowanie Po co mielić puste powietrze lub cisnąć się na zbyt małej liczbie węzłów? Wtedy z pomocą przychodzi oficjalny projekt autoscaler.\nZareaguje on odpowiednio na potrzeby i zarządzi odpowiednią węzłami - zwiększy lub zmniejszy ich liczbę.\nJest tylko mały problemik - utworzy on węzły o jednym typie. To jest w większości wypadków ok, ale jeśli potrzebujesz dodatkowego węzła na zaledwie kilka podów to może utworzenia węzła mieszczącego ich kilka(naście) razy więcej nie być optymalne.\nDo tego może te nowe pody mogą działać na węzłach typu spot - wtedy tradycyjny autoskaler może być niewystarczający. Ale na szczęście jest coś lepszego.\nMądrzejszy dobór węzłów z dodatkiem Karpenter Tym czymś jest projekt Karpenter. Jest to bardziej inteligentny autoskaler, który zadba o lepszy dobór węzłów.\nTo dobra wiadomość, ale jest też zła. Póki co wspiera tylko AWS (oni go z resztą utworzyli) oraz Azure. Na resztę przyjdzie nam jeszcze poczekać.\n","tags":["autoskalowanie","cloud","karpenter","kubernetes"],"title":"Newsletter #94 - Jak najlepiej dobrać węzły do klastra"},{"categories":["ebooks"],"date":"January 3, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/ebooks/darmowy-klaster-kubernetes/","section":"ebooks","summary":"https://darmowyklaster.cloudowski.com/\n","tags":["kubernetes","friko","cluster","cloud"],"title":"(PL) Darmowy klaster Kubernetes w chmurze"},{"categories":["newsletter"],"date":"January 2, 2024","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/93/","section":"newsletter-archive","summary":"Jeśli czytasz mój newsletter od jakiegoś już czasu to wiesz, że obok technicznych tematów pojawiają się u mnie też tzw. tematy “miękkie”.\nTo dlatego, że rozwój w stronę eksperta wiąże się nie tylko z umiejętnościami twardymi, ale idzie w parze z rozwojem pozatechnicznych aspektów naszej kariery.\nPoczątek roku to tradycyjne postanowienia noworoczne. Może to wynika z naszego przywiązania do liczb i dat, a może faktycznie jest to wyraz naszej potrzeby zmiany czegoś. Dzisiaj podzielę się moimi przemyśleniami na ten temat.\nCzy postanowienia działają? Według mnie każda szansa na podjęcie działań jest warta. Niech to będzie nawet i taka trochę wymuszona cyklem zmiany daty w kalendarzu.\nTo może być nowe otwarcie i kolejne podejście do nękającej nas potrzeby, ale tym razem z bagażem nowych doświadczeń zdobytych w ostatnich 12 miesiącach.\nMoże też mamy nową motywację związaną ze zdarzeniami niezależnymi od nas. Może los sprawił, że dostaliśmy kopniaka (np. koniec projektu, redukcja zatrudnienia w firmie, nowy irytujący szef/szefowa) lub mocniej pragniemy TEJ zmiany (zmiana pracy, większe zarobki, szacunek “na dzielni” itp.).\nJak dotrzymać postanowień bez wysiłku? Nie wiem. Poważnie - nie znalazłem cudownej metody i to prawdopodobnie dlatego, że… jej po prostu nie ma!\nZ pewnością zobaczysz teraz dużo reklam o tym jak “wystarczy zrobić XYZ, aby …”, ale może już wiesz, że będzie wymagany wysiłek.\nNasz mózg ma jedno zadanie - pomóc nam przetrwać. To w myśl zasady “działa - nie ruszaj”.\nStąd ciężko jest nam się zmusić, bo musimy walczyć z tym naturalnym stanem inercji. A mózg da nam mnóstwo “racjonalnych” wymówek dlaczego ta inercja nie jest taka zła.\nDlatego czasem trzeba uwierzyć, że to nie będzie trudne, aby oszukać mózg i ruszyć do przodu. I może faktycznie te zapewnienia w reklamach siłowni i innych metod na zmianę mogą pomóc nam przekonać się do wykonania tego pierwszego i jakże ważnego, małego kroku.\nStatystyki są przeciwko nam Według tych statystyk tylko 6% osób zostaje przy swoich noworocznych postanowieniach. Ja z kolei słyszałem o tym, że styczeń jest miesiącem, gdzie siłownie przeżywają oblężenie tzw. “postanowień noworocznych”. Podobno około 20% z takich osób zostaje na siłowni faktycznie na dłużej.\nNie są to porywające liczby. Ale wiesz co? Lepsze te 6% czy 20% niż narzekanie, że i tak się nie uda. Bo może być tak, że to nie pierwsze podejście tych osób, które wytrwały. Możliwe, że kilka lub kilkanaście razy odpuszczały. Ale nie tym razem. Tym razem znalazły siłę i motywację do wytrwania.\nAle najważniejsze to… … próbować, próbować i wciąż próbować. Jak nie tym razem to kolejnym. Obserwować co poszło nie tak i kolejnym razem zmieniać.\nJa podchodziłem do moich projektów (m.in. przygotowanie kursu, systematyczne pisanie newslettera) wiele razy. Czasem zatrzymywałem się tylko na myśleniu o tym. Innym razem skupiałem się na idealnych narzędziach, bo walczyłem z wewnętrznym perfekcjonistą.\nWielokrotnie znajdowałem wymówki, aby się poddać i tak faktycznie robiłem. Aż do czasu, gdy postawiłem na swoim, nie poddałem się wątpliwościom i inercji - zacząłem działać.\nMi pomogło jedno postanowienie (i przestawienie w głowie) - cokolwiek robię jest dla mnie lekcją. Nawet jeśli nie osiągnę celu to dlatego, że nie byłem gotowy.\nCzasem nie dowiozę czegoś już nigdy, bo się dowiedziałem w trakcie, że nie jest to dla mnie już ważne. Czasem dowiaduję się czegoś o sobie co pozwala mi zmienić cel lub metody dotarcia do niego.\nWszystko jest lekcją. Dlatego warto próbować i dawać sobie przyzwolenie na błądzenie. Ważne, aby próbować, obserwować i dostosowywać pod siebie.\n","tags":["rozwój-osobisty"],"title":"Newsletter #93 - Czy postanowienia noworoczne mają sens?"},{"categories":["newsletter"],"date":"December 19, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/92/","section":"newsletter-archive","summary":"Wiele osób pytało mnie czego się uczyć. Stąd poświęciłem czas na przygotowanie kilku projektów do samodzielnej nauki technologii z obszaru DevOps.\nMoże lubisz sam do wszystkiego dochodzić, może szukasz inspiracji i zawężenia obszaru poszukiwań. Dlatego dzisiaj ma uroczysta premiera mojego projektu do samorozwoju umiejętności.\nJeśli nie umiesz tak jak ja piec serników czy lepić pierogów to właśnie dostarczam Ci wymówkę na spędzenie wolnego czasu i “ucieczkę” od obowiązków ;)\nA tak poważnie to spędź ten okres z najbliższymi, a do projektów wróć już po!\nProjekty do “self-study” Przygotowałem dedykowaną stronę selfstudy.cloudowski.com, na której znajdziesz projekty do przygotowania.\nOpis jest na stronie głównej, a tutaj przytoczę tylko najważniejsze rzeczy.\n**Koncept\n** To dość proste - bierzesz projekt (najlepiej po kolei, bo są w pewien sposób ze sobą powiązane) i dobierasz narzędzia, aby spełnić opisane wymagania.\nJeden projekt może zająć Ci kilka godzin, kilka dni lub tygodni - to wszystko zależy od Twoich obecnych umiejętności i czasu jaki poświęcisz na nauczenie się tych brakujących.\nJak znaleźć pomoc **\n** Oczywiście polegasz na ogólnej wiedzy dostępnej w internecie. Jeśli utkniesz to zapraszam na dedykowany kanał #selfstudy na moim serwerze Discord.\nWkrótce też pojawią się podstrony ze wskazówkami, ale to uzależnione jest od tego czy faktycznie będzie zainteresowanie tymi projektami.\n**Daj znać co o tym myślisz\n** Jeśli masz pomysł jak to usprawnić to daj mi znać osobiście lub zrób PR na repozytorium korzystając z przycisku na stronie (pracuję nad tym i wkrótce będzie to możliwe).\nMam kilka innych pomysłów w zanadrzu i chętnie je opublikuję jeśli pomysł chwyci.\nNarzędzie tygodnia - oszczędź na prąd na 🎄 Projekt https://sustainable-computing.io/ może przydać się osobom, które mają własny sprzęt lub też chcą dokładniej raportować/śledzić zużycie prądu.\nMoże na on-prem nie da się oszczędzić tyle ile w chmurze, ale wyłączanie nieużywanych serwerów może przynieść sporo oszczędności.\n","tags":["cloud","devops","docker","edukacja","kubernetes"],"title":"Newsletter #92 - Sprawdź swoje umiejętności z moim nowym projektem"},{"categories":["newsletter"],"date":"December 12, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/91/","section":"newsletter-archive","summary":"Dzisiaj tematów kilka i będzie o uaktualnionym ebooku, o temacie głównym dla wszystkich korzystających z Kubernetesa i na koniec o ciekawym narzędziu dla zarządzających własnymi klastrami.\nUaktualniony e-book o darmowym klastrze Dokonałem ostatnio przeglądu mojego ebooka, który umożliwia uruchomienie czterowęzłowego klastra w chmurze.\nPrzy okazji zaktualizowałem go i uszczegółowiłem kilka elementów – głównie tych związanych z ustawianiem load balancera dla dostępu i dla Ingressu, ponieważ wymagany był dodatkowy krok.\nZ tej okazji dodałem do swojej osobistej kolekcji dodatkowy klaster i teraz mam już łącznie dwa. Mojego pierwszego używam już od ponad dwóch lat nie płacąc ani grosza, a ostatnio nawet zaktualizowałem go do najnowszej wersji kubernetesa (całość operacji trwała około 10 minut).\nJeśli masz ochotę to zapraszam do jego pobrania.\nIngress czy Service? Ostatnio prowadziłem szkolenie gdzie ponownie temat Ingress był tym najtrudniej przyswajalnym. Widziałem to po oczach ludzi, gdy tłumaczyłem różnice między load balancerami L7 i L4 w oparciu o model ISO/OSI.\nDla tych co mają do czynienia z sieciami temat nie jest tak skomplikowany, a dla reszty zasada użycia jest dość prosta:\nJeśli chcesz puszczać coś na zewnątrz i jest to aplikacja komunikująca się po http to w większości wypadków użyjesz obiektu Ingress.\nW przeciwnym wypadku pozostaje Ci obiekt Service typu Load Balancer. Pewnym wyzwaniem może być jedynie brak jego obsługi w przypadku własnych klastrów poza chmurą, ale to da się ogarnąć co omawiam w jednym z modułów części Pro mojego kursu.\nA co z ruchem wewnątrz klastra?\nService dla ruchu wewnętrznego To wydaje się dość proste – dla ruchu wewnętrznego używamy obiektu Service typu ClusterIP. Jest to uniwersalne rozwiązanie, które zadziała zawsze i wszędzie niezależnie od tego gdzie jest uruchomiony klaster.\nAle w przypadku klastra w chmurze możliwe jest również użycie typu Load Balancer. Dostawcy tacy jak AWS, Azure czy GCP umożliwiają użycie ich natywnych load balancerów dla ruchu wewnątrz klastra.\nTo może mieć sens jeśli chcesz użyć zaawansowanych funkcji takich jak connection draining, logowanie ruchu czy natywna integracja z ich usługami (np. WAF).\nA czemu by nie użyć zaawansowanych funkcji Ingress do tego typu ruchu?\nIngress wewnątrz klastra? Większość używa ingresu dla ruchu zewnętrznego, bo z to ogranicza koszty, ułatwia zarządzanie i umożliwia wykorzystanie funkcji protokołu http do kontroli ruchu.\nPodobnie Ingress może być użyty dla ruchu wewnętrznego! Nie jest to popularne, ponieważ przypadków użycia nie ma tak dużo. Wiąże się to też z potencjalnie większymi opóźnieniami, gdyż przekazywanie ruchu http wykonywane jest przez oprogramowanie (kontrolery Ingress), a nie sam kernel jak w przypadku ruchu sieciowego (load balancery ustawianie przez Service).\nIngress może być dobrym sposobem na rozdzielenie aplikacji webowych komunikujących się wewnątrz klastra. Mogą to być mikroserwisy z różnych bounded contextów z Domain-driven Design ( DDD).\nMoże być to też konieczność filtrowania ruchu na L7 lub używania funkcji takich jak sticky sessions, szyfrowanie TLS, mTLS, uwierzytelnianie, autoryzacja lub innych.\n🧰 Narzędzie tygodnia Zbudowałeś klaster i szukasz lepszego sposobu na aktualizację węzłów?\nPolecam projekt od Adobe - k8s-shredder. Dzięki niemu szybciej i sprawniej zaktualizujesz klaster z łagodnymi krokami niwelującymi przerwy w dostępie do uruchomionych serwisów.\n","tags":["cloud","ingress","kubernetes","loadbalancer","onprem"],"title":"Newsletter #91 - Jaki load balancer wybrać dla usług w klastrze"},{"categories":["newsletter"],"date":"December 5, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/90/","section":"newsletter-archive","summary":"Poprzednia część przypadła do gustu i zatem dzisiaj kontynuacja najciekawszych prezentacji z niedawnej konferencji KubeCon 2023 North America.\nTo co obejrzałem daje mi powody do wniosku, że ekosystem Kubernetesa i Cloud Native, nie licząc modnego AI, skupia się głównie na usprawnianiu GitOps i koncepcji budowania platform (czyli Platform Engineering).\nI dzisiaj zajmię się tymi tematami właśnie.\nBudowanie platform i GitOps Zacznę od najlepszej według mnie prezentacji, którą obejrzałem z tej konferencji. Bo ma ona elementy, których zawsze szukam, czyli:\n- ciekawy temat z przykładami\n- ciekawe slajdy bez ton tekstu będące tłem do opowieści\n- ciekawie i pewnie prowadzona ta opowieść\n- dużo tematów w odpowiedniej proporcji prosto/technicznie\n- trochę humoru\nW tej prezentacji zobaczysz jak Spotify radzi sobie z własnymi klastrami, jak do tego używa GitOps i jakie ma wyzwania z deklaratywnością (i jej brakiem).\n💡 Wskazówki dla Ciebie: Kubernetes jest do budowy platform. Te zbudujesz na kontenerach, zarządzisz przez GitOps, a developerom udostępnisz w portalu (Internal Developer Platform) jak np. Backstage.\nJeśli używasz Argo CD lub planujesz go użyć do GitOps to może ucieszy cię, że interfejs webowy może być rozbudowany o Twoje własne elementy. Zobacz w tej prezentacji jakie elementy możesz dodać, a dla specyficznych scenariuszy posłużyć to może jako portal IDP.\n💡 Wskazówki dla Ciebie: Chyba czas na naukę JavaScript, bo poza tym zastosowaniem przyda się też do konfiguracji Backstage i pisania aplikacji w WASM.\nHelm Charty są wszędzie i nawet jak ich nie tworzysz (np. wybrałeś Kustomize lub inny sposób) to zarządzając nimi w stylu GitOps rodzą się pytania jak to pożenić ze sobą, gdzie trzymać parametry (values) i jak deklaratywnie skonfigurować to w Argo CD.\nW tej prezentacji zobaczysz ciekawe demo i jeden ze sposobów na integrację.\n💡 Wskazówki dla Ciebie: Unifikuj i twórz konwencje. To usprawni wszystkim pracę, a dobry GitOps jest motorem napędowym kolejnych zmian, bo te są łatwo odwracalne w razie wpadki, której tak często się boimy.\nDobry GitOps to też bezpieczeństwo w kodzie, a to obok RBAC warto wymuszać przez Admission Controllery typu Kyverno.\nJest jednak dobra wiadomość - od wersji 1.28 w Kubernetesie jest natwyny mechanizm filtrowania, a ta prezentacja w prosty sposób z ciekawym demo pokazuje o co chodzi z CEL.\n💡 Wskazówki dla Ciebie: Kubernetes ma “ułomne” mechanizmy zabezpieczenia API - RBAC nie ma reguł wyłączających i tylko dzięki CEL lub rozwiązaniom typu Kyverno lepiej ogarniesz reguły bezpieczeństwa.\nTen projekt idzie jak burza! Mówię tu o OpenTelemetry. Ustanawia on standardy dla observability, czyli głównie:\n- trace\n- monitoring\n- logowanie\nTa prezentacja pokazuje jak dużo już zostało zrobione i jakie języki są już w pełni wspierane dla instrumentacji, łącznie z logami.\n💡 Wskazówki dla Ciebie: Monitoring to nie tylko Prometheus, Logi to nie Logstash/Filebeat/Splunk, trace’y to nie Jaeger/Zipkin/OpenTrace - niedługo będziemy mieli ujednolicony standard, a projekty/produkty będą dorzucać swoje ficzery (np. GUI, bo tym OpenTelemetry się nie zajmie).\nTo tyle z najciekawszych prezentacji. Jak znalazłaś/znalazłeś coś ciekawego to daj znać - uzupełnię w przyszłym newsletterze.\n","tags":["argocd","backstage","gitops","idp","kubecon","kubernetes","opentelemetry","wasm"],"title":"Newsletter #90 - Jak dobrze zaprojektować GitOps"},{"categories":["newsletter"],"date":"November 28, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/89/","section":"newsletter-archive","summary":"Zrobiłem to. Przejrzałem udostępnioną kilka dni temu listę 310 nagrań z KubeCon 2023 North America i zebrałem najciekawsze nagrania wraz ze wskazówkami.\nTrochę mi to czasu zajęło, ale było warto, bo mogę się teraz tym z Tobą podzielić. O dziwo nie będzie tego super dużo, bo wiele prezentacji było nieciekawych, zbyt podstawowych lub osobiście niezrozumiałych.\nTo jednocześnie pokazuje, że warto próbować zgłaszać się na konferencje - Twoja może być po prostu lepsza od średniej (ta nie jest zbyt wysoka jak widać 🙂)\nDzisiaj pierwsza część, a za tydzień druga.\nSkalowanie klastrów i ograniczanie kosztów Często słyszę zarzut, że skalowanie klastrów Kubernetesa jest czasem zbyt wolne. Wiedzą coś o tym ludzie utrzymujący platformę dla jednej z najbardziej wpływowych gazet na świecie - The New York Times. Zobacz jak sobie radzą z tym u siebie.\n💡 Wskazówki dla Ciebie: Zobacz Karpenter i KEDA\nPody to kontenery, a kontenery to procesy. Te uruchomione są na serwerach i to jakie to serwery, czy raczej typy instancji w chmurze, ma duży wpływ na koszty. W tej prezentacji zobaczysz, że tanie instancje w chmurze mogą wcale nie wychodzić tak tanio. W prezentacji jest fajna tabelka, która zestawia typy dla trzech dostawców chmury.\n💡 Wskazówki dla Ciebie: Węzły klastra nie mogą być za małe, ale jednocześnie zbyt duże też nie (współdzielone zasoby kernela linuksowego mogą zacząć być wąskim gardłem).\nCzy to już poszło za daleko? No bo jak wytłumaczyć fakt, iż są rozwiązania, które skalując klastry biorą pod uwagę… ślad węglowy! Zobacz w tej prezentacji jak to działa. Duże korporacje często mają w swojej polityce cele zmniejszania śladu węglowego i to można osiągnąć również w taki sposób.\n💡 Wskazówki dla Ciebie: Widać raz jeszcze, że KEDA jest dobrą alternatywą dla HPA i o wiele prostszą o dziwo.\nZ tej prezentacji z kolei dowiesz się o wielu innych wskazówkach, które pozwolą Ci zmniejszyć koszty działania klastra. Widać, że organizacje tną koszty, bo kto chciałby przepłacać? Na szczęście to nie jest takie trudne.\n💡 Wskazówki dla Ciebie: Koszty instancji to nie wszystko. Użycie serwisów typu Load Balancer i odpowiednich wolumenów może być kluczowe.\nJeśli masz wdrożone Istio lub dopiero to planujesz to zobacz to wideo, gdzie pokazane jest nad czym skupia się projekt oraz to jak użycie trybu Ambient może radykalnie obniżyć koszty całego rozwiązania.\n💡 Wskazówki dla Ciebie: Jeśli zależy Ci głównie na zwiększeniu bezpieczeństwa ruchu to nie ma sensu wdrażać Istio z kontenerami - wystarczy do tego tryb Ambient.\nI to tyle tym razem - za tydzień część druga skupiona wokół GitOps.\n","tags":["autoskalowanie","cloud","istio","karpenter","keda","koszty","kubecon","kubernetes"],"title":"Newsletter #89 - Jak dobrze skalować klastry i ograniczyć koszty"},{"categories":["newsletter"],"date":"November 21, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/88/","section":"newsletter-archive","summary":"Na początku mam dwa ogłoszenia, a w dalszej części dzielę się spostrzeżeniami dotyczącymi budowy środowisk na on-prem.\nOgłoszenie 1 - nowy odcinek podcastu Po dłuższej przerwie wracam do nagrywania podcastu. Tym razem usiadłem sam ze sobą i nagrałem odcinek, w którym opowiadam jak tworzyłem mój kurs Kubernetes po polsku i czego się z tego nauczyłem.\nZdradzam w nim wiele szczegółów pracy “od kuchni” i posłuchaj, aby dowiedzieć się między innymi:\nJakie miałem wątpliwości przed jego rozpoczęciem? Dlaczego przedsprzedaż była tak ważna? Z czym się zmagałem najbardziej przy tworzeniu materiałów? Co wpłynęło na duże opóźnienia w jego publikacji? Jak wytworzyłem dwie osobowości, które pomogły mi dowieźć to do końca? Podcast “Rozchmurzony” jest dostępny do przesłuchania na wszystkich popularnych platformach oraz również na YouTube.\nOgłoszenie 2 - Promocja na przypakowanie wiedzą Jako, że okazja taka jest raz w roku ( BLACK FRIDAY) to specjalnie w najbliższy piątek włączam sprzedaż moich kursów po promocyjnej cenie.\nCzasu nie będzie dużo, bo zaledwie 24 godziny. To wystarczy, aby podjąć dobrą decyzję i jeśli czekałeś na okazję wymasterowania się z Kubernetesa to kolejna będzie dopiero w przyszłym roku.\nInformację przypominającą o sprzedaży wyślę do wszystkich zapisanych na listę na stronie kursu oraz umieszczę na moich kontach social media (LinkedIn, YouTube, Instagram).\nLista kursów będzie dostępna na stronie https://edu.cloudowski.com/.\nWracając teraz do tematu głównego – dlaczego środowiska on-prem przeżywają swój renesans?\nLiczy się każdy grosz Chmura publiczna jest naprawdę genialna, bo bez jakiejkolwiek inwestycji uzyskujesz dostęp nie tylko do zasobów, ale też gotowych usług z których możesz budować naprawdę zaawansowane rozwiązania.\nJak pokazują raporty wyników finansowych największych spółek oferujących takie usługi, ten biznes naprawdę się opłaca. To znaczy opłaca się na pewno dla nich i do pewnego czasu również dla klientów.\nWiele firm przekonało się, że przekraczając pewną skalę cloud zaczyna być po prostu drogi lub nawet bardzo drogi. Jednocześnie nie wszyscy potrzebują zaawansowanych usług i opierają się głównie tylko na kilku (m.in. instancje maszyn wirtualnych, vpc i sieciówka, storage, CDN).\nI wtedy do łaski wracają tradycyjne serwery i środowiska on-prem. Przy odpowiedniej skali zaczynają one być o wiele tańsze, w szczególnościm gdy są prawie tak samo dobrze zautomatyzowane jak cloud, a to jest już obecnie naprawdę proste dzięki Kubernetesowi. Część organizacji rezygnuje nawet z płatnych produktów do wirtualizacji.\nKubernetes chodzi na wszystkim Środowiska Cloud Native oparte o kontenery nie wymagają tylu zabezpieczeń przed awariami jak te oparte o tradycyjne maszyny wirtualne. Klastry obronią się przed większością awarii, a dobrze zaprojektowane środowiska odporne są również na awarię całych klastrów, ponieważ są zbudowane w wielu lokalizacjach geograficznych w trybie multi-cloud czy też multi-region.\nWidziałem organizacje, które używały zakupionego przed laty sprzętu do postawienia naprawdę dużych klastrów deweloperskich. Taki sprzęt może zyskać nowe życie i przyczynić się do sprawniejszego wdrażania skonteneryzowanych rozwiązań.\nNawet kiedy konieczne jest zakupienie nowego sprzętu to nie musi on być z najwyższej półki i nie musi też zawierać redundancji wszystkich komponentów, ponieważ to może przejąć orkiestrator Kubernetesa Uruchamiając pody z aplikacjami na innych zdrowych węzłach. Do tego dorzucimy jeszcze węzły na architekturze ARM i mamy naprawdę na czym poszaleć zachowując wysoki poziom bezpieczeństwa oraz wydajności przy ograniczonych kosztach.\nBezpieczeństwo i polityka Koronnym argumentem przytaczanym przez zaciekłych zwolenników własnych serwerów jest bezpieczeństwo danych. Wiedzą to dostawcy chmury i stąd wiele energii wkładają w zapewnienie klientów, że dane przesyłane do nich będą bezpieczne, a w przypadku RODO nie opuszczą one danego regionu (czyli np. Unii Europejskiej).\nDo tego mogą dojść wewnętrzne polityki organizacji, która zainwestowała sporo środków na dzierżawę lub zakup sprzętu i pomimo zapewnień dostawców woli trzymać dane u siebie. To może mieć duży sens pod jednym warunkiem – jeśli istnieje zespół ekspertów potrafiący stworzyć i utrzymać środowisko zbliżony sposób do tego jaki oferuje cloud.\nZanim rzucisz chmurę… Przyszedł czas na łyżkę dziegciu w tych rozważaniach. Wielokrotnie na szkoleniach i w pracy z moimi klientami powtarzam, że Kubernetes przynosi naprawdę niesamowity poziom automatyzacji dla środowisk on-prem, ale obarczone jest to zwiększonym wysiłkiem. Nie przesadzę jeśli powiem, że utworzenie pełnego produkcyjnego klastra Kubernetes o odpowiednim rygorze ( wydajność, bezpieczeństwo, niezawodność) może być dziesięciokrotnie trudniejsze.\nW chmurze nie musisz dotykać wielu elementów, które na środowisku są konieczne do skonfigurowania. Chmura dodaje kolejne warstwy abstrakcji do tych, które tworzy sam Kubernetes, aby przykryć złożoność tego co się dzieje pod spodem. To wszystko, aby ułatwić korzystanie z zaawansowanych funkcji dostępnych wcześniej dla wybranych magików.\nW przypadku on-prem potrzebna jest o wiele większa wiedza dotycząca między innymi Linuxa, sieci, tworzenia rozwiązań storage, load balancingu, wydajności i diagnozowania problemów na styku sprzętu i oprogramowania oraz wiele, wiele innych.\nBudując w ten sposób środowiska potrzebujesz po prostu wiedzy, aby zagłębić się w obszary, które warstwy abstrakcji zakrywają. Jest to do zrobienia, ale wymaga zbudowania większego portfolio umiejętności. Może to dać organizacji olbrzymie oszczędności oraz też mnóstwo satysfakcji dla zespołu tworzącego i rozwijającego takie rozwiązania.\nTrzymam kciuki za tych, którzy budują rozwiązania na własnym sprzęcie lub też rozwiązania hybrydowe. To są wspaniałe czasy, aby odkurzyć wiedzę sprzed lat i wzbogacić ją o nowe zabawki (czyt. projekty Cloud Native z Kubernetesem jako platformą)!\n","tags":["containers","devops","docker","kubernetes","onprem"],"title":"Newsletter #88 - Renesans środowisk on-prem"},{"categories":null,"date":"November 19, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/19/","section":"podcast","summary":"Wracam tym razem solo. W tym odcinku opowiadam o tym jak tworzyłem mój kurs Kubernetes po polsku i czego się z tego nauczyłem.\nZdradzam w nim wiele szczegółów pracy “od kuchni” i posłuchaj, aby dowiedzieć się między innymi:\nJakie miałem wątpliwości przed jego rozpoczęciem? Dlaczego przedsprzedaż była tak ważna? Z czym się zmagałem najbardziej przy tworzeniu materiałów? Co wpłynęło na duże opóźnienia w jego publikacji? Jak wytworzyłem dwie osobowości, które pomogły mi dowieźć to do końca? ","tags":["biznes","kubernetes","kurs"],"title":"19 - Jak robiąc kurs stworzyłem dwie osobowości"},{"categories":["newsletter"],"date":"November 14, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/87/","section":"newsletter-archive","summary":"Łatwo jest postawić wiele klastrów z Kubernetesem, zapuścić kilka manifestów, dograć Helm Charty i odtrąbić sukces.\nW codziennym, szarym życiu liczy się bardziej to co dzieje się później. W użytkowaniu platformy bardzo duży wpływ ma dostępność nowych wersji Kubernetesa oraz łatanie dziur i podatności. To jak obsługiwana jest platforma dla aplikacji jest widoczne bardziej dla organizacji i jej klientów niż jakieś nowinki technologiczne.\nTym razem przyjrzę się tematowi aktualizacji klastrów.\nWersjonowanie Kubernetesa Czy wiesz jak jest wersjonowany kubernetes? Podlega on konwencji wersjonowania semantycznego i każda wersja zawiera trzy człony:\nMAJOR.MINOR.PATCH\nMAJOR - niezmieniona od 2015 wersja główna. Obecnie jest to “1” i tylko przy naprawdę olbrzymich zmianach będzie ona podniesiona. Nie zapowiada się jednak, aby nastąpiło to w najbliższych latach. MINOR - mniejsze aktualizacje wprowadzające czasem dość istotne zmiany, ale w dużym stopniu zachowujące kompatybilność wsteczną. Projekt Kubernetes wypuszcza trzy takie wersje w ciągu roku. PATCH - to małe, wręcz znikome zmiany które łatają dziury nie zmieniając przy tym samego API. Każda wersja minor dostarcza takie patche w okresie do jednego roku od jej wypuszczenia. Oznacza to, że musisz zaktualizować klaster przynajmniej raz w roku, bo w przeciwnym wypadku zostaniesz z wersją, do której już nie ma aktualizacji (również takich które mogą wprowadzić realne niebezpieczeństwo dla twoich danych!). Te poszczególne wersje są wykorzystywane przez kanały aktualizacji.\nCzym są kanały aktualizacji Ten koncept dzieli sposób dostarczania aktualizacji w zależności od potrzeb używania nowych funkcjonalności Kubernetesa, a przede wszystkim od akceptowalnego poziomu ryzyka jakie to niesie ze sobą.\nNiektóre usługi kubernetesa w chmurze oraz dystrybucje on-prem obsługują takie kanały. Koncepcja jest bardzo podobna, chociaż nazewnictwo kanałów może być różne.\nWyróżniamy z reguły trzy kanały aktualizacji, które mogą być przypisane do klastra. Są to:\nRAPID - kanał progresywny, który dostarczy aktualizacje najszybciej jak tylko dostawca przygotuje odpowiednie paczki dla usługi lub dystrybucji z najnowszą wydaną przez projekt wersją\nSTABLINY - kanał standardowy, który nowe wersje minor kubernetesa dostarczy z pewnym opóźnieniem, a do tego czasu dostarczy poprawki, czyli najnowsze wersje patch\nKONSERWATYWNY - jak nazwa sugeruje jest to kanał skupiający się głównie na dostarczaniu najnowszych wersji patch. Klaster z tak podpiętym kanałem będzie najdłużej utrzymywał wersję major i tym samym będzie doskonałym kandydatem dla wersji produkcyjnych.\nA które platformy wspierają kanały aktualizacji?\nZ dużych graczy są to GKE i AKS, ale nie EKS co jest wręcz szokujące 🤯\nZ popularnych dystrybucji dla on-prem to oczywiście OpenShift od Red Hata i RKE2 od Ranchera/SuSe.\nKiedy użyć autoaktualizacji Moja rekomendacja to aktualizować automatycznie jeśli tylko jest taka możliwość. Największą przeszkodą może być bardzo konserwatywne i unikające nawet najmniejszego ryzyka podejście stosowane w danej organizacji. Są takie sektory, gdzie zmiana musi być naprawdę solidnie przetestowana, aby mogła dojść do produkcji czy nawet stage.\nMoim zdaniem tam również jest to możliwe do osiągnięcia poprzez dobre zarządzenie procesem aktualizacji. Zatem jeśli masz więcej niż jeden klaster i w szczególności gdy jest on w chmurze (no chyba, że masz EKS…) to nie wahałbym się zbyt długo i użyłbym kanałów aktualizacji w trybie automatycznym.\nA jaką wtedy strategię wybrać?\nJaka strategia aktualizacji jest najlepsza Duża część zacznie pewnie od ręcznej aktualizacji, aby sprawdzić jej działanie i wyłapać ewentualne problemy. To może być pierwszy krok przed włączeniem automatu ale również wersja dla super ostrożnych. Tutaj jednak pojawia się ryzyko utknięcia w błędnym kole.\nWidziałem to już wielokrotnie i sam byłem tego ofiarą. Na czym ono polega?\nNa początku opóźniasz nieznacznie wprowadzenie nowej wersji, bo boisz się, że ona coś zepsuje. Mija więcej czasu, pojawiają się nowe wersje, które wprowadzają jeszcze więcej zmian. Twój strach o to, że one coś zepsują jeszcze bardziej narasta. Powoduje on, że masz jeszcze więcej powodów na to aby nie zaktualizować do kolejnej wersji. I tak tkwisz w tym błędnym kole dotąd aż coś lub ktoś zmusi cię do aktualizacji i zamiast obsłużyć to małymi krokami zmuszony jesteś do wykonania jednej WIELKIEJ zmiany. I zgadnij co. – wtedy spełni się twoja przepowiednia i faktycznie coś może pójść nie tak bo zmian będzie już zdecydowanie więcej niż gdybyś robił to regularnie.\nW przypadku automatycznego aktualizowania polecam strategię waterfall. Polega ona na przypisaniu różnych kanałów do różnych klastrów tak, aby klastry nieprodukcyjne aktualizowały się nowszymi wersjami wcześniej niż klastry typu stage lub prod. Pozwala to na przetestowanie zmian i wprowadzenie ewentualnych modyfikacji do manifestów.\nA co jeśli nie ma kanałów aktualizacji Nie musisz od razu wpadać w panikę, ale też pamiętaj aby nie wpaść w błędne koło. Zaplanuj samodzielnie harmonogram aktualizacji i poinformuj o tym wszystkie zainteresowane strony. Na początku może być opór, ale musisz się tego trzymać, aby przyzwyczaić organizację do tych zmian i przede wszystkim zadbać o sprawne funkcjonowanie platformy.\nJeśli brak kanałów aktualizacji wynika z początkowej decyzji co do wyboru dystrybucji to może być to okazja do jej zmiany w przypadku kolejnych projektów. Pamiętaj, że kompatybilność będzie zachowana - to gwarantuje specyfikacja API kubernetesa.\nA jeśli masz EKSa to nie pozostaje nic innego jak pisać do AWS petycję o wprowadzenie tej podstawowej funkcjonalności dla dojrzałych usług Kubernetesa w chmurze.\n","tags":["cloud","containers","devops","kubernetes","onprem"],"title":"Newsletter #87 - Jak aktualizować klastry?"},{"categories":["newsletter"],"date":"November 7, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/86/","section":"newsletter-archive","summary":"Ile klastrów Kubernetesa to za mało, a ile za dużo? To pewnie zależy pod zastosowań, wielkości organizacji, jej struktury, polityki i wielu innych czynników.\nJa postanowiłem tym razem przyjrzeć się bliżej temu tematowi i pomóc Ci w odpowiednim wyborze przy projektowaniu lub rozbudowie Twojego środowiska.\nPo co wiele Zacznijmy od powodów, dla których potrzebnych jest wiele klastrów. Poniżej wymieniam najważniejsze według mnie.\nPierwszy to jednocześnie najważniejszy - izolacja środowisk. Ja nazywam to twardą izolacją, bo najskuteczniej oddziela środowiska developerskie od stage i produkcji.\nDrugi powód to aktualizacje. Dotyczy to głównie nowych wersji Kubernetesa. O konieczności aktualizacji chyba nie muszę wspominać, a posiadanie wielu klastrów umożliwia wyłapanie większych wpadek spowodowanych np. przez zmiany w API oraz wyłączenie pewnych funkcjonalności jak swego czasu zastąpienie PodSecurityPolicy przez PodSecurity.\nTrzeci to eksperymenty. Bez nich Twoje środowisko nie będzie mogło być usprawnianie przez dodawanie nowych funkcji. Te mogą nieść ze sobą ryzyko, a raczej nie chcesz, aby się zmaterializowało na produkcji. Ten element wspomaga też uczenie - bez tego utkniesz wraz z Twoimi zespołami w miejscu.\nCzwarty to dostęp do API. Po części związane jest to z izolacją, ponieważ wiele klastrów umożliwia podział kto może się do nich połączyć. Ma to jednak też inne zastosowanie. Możliwe jest wówczas podzielenie klastrów na te, które umożliwiają podłączenie się bezpośrednie użytkownikom i takie, które na to nie zezwalają. Te ostatnie zarządzane są bowiem jedynie w stylu GitOps, a dostęp jest w trybie awaryjnym tylko dla wybranych.\nPiąty powód to wysoka dostępność czy raczej Disaster Recovery. Dotyczy to głównie środowisk produkcyjnych o krytycznym znaczeniu. Jeśli redundancja komponentów control plane i odpowiedniej dystrybucji instancji aplikacji po węzłach jednego klastra nie wystarczy to potrzebujesz pójść krok dalej. Wkraczasz wówczas na pole środowisk multi-cluster w trybach od active-passive do active-active w ramach jednego dostawcy lub wielu oraz różnych lokalizacji geograficznych.\nTylko jeden A po co komu więcej? Może jeden wystarczy? 🤔\nSą sytuacje, gdy faktycznie pojedynczy klaster służy za wszystko od środowisk testowych po produkcję. Przemawia za tym przede wszystkim niższy koszt oraz prostota w utrzymaniu. To może mieć duże znaczenie w przypadku małych zespołów, gdzie ogarnianie wielu klastrów może zajmować zbyt wiele czasu.\nKolejnym przypadkiem może być też środowisko on-prem, gdzie instalacja kolejnych klastrów oraz jakakolwiek zmiana to dni lub tygodnie wymiany maili z osobami odpowiedzialnymi za serwery.\nCzy da się na pojedynczym klastrze mieć wiele środowisk z produkcją włącznie? Owszem i Ci co widzieli część PRO mojego kursu wiedzą już, że możliwe jest zaimplementowanie tzw. miękkiej izolacji i nawet wydzielenie puli węzłów na poszczególne środowiska (moduł 7 lekcja 3 🙂).\nTaki układ jest dobry na start, ale na dłuższą metę sprawia sporo problemów np. przy aktualizacjach Kubernetesa (szczególnie tych mniej “udanych”).\nDwa światy Tak jak kiedyś dodanie kolejnego rdzenia procesora do jednordzeniowego serwera czyniło go o wiele szybszym (kolejne już nie przynosiły tak spektakularnej różnicy) tak rozdzielenie środowisk na dwa klastry robi zasadniczą różnicę.\nTworzysz wówczas dwa światy. Jeden nieprodukcyjny i drugi produkcyjny. Ten pierwszy możesz nazywać dev, test, stage lub nawet krainą swobody i rozpusty 😉 Ważne, aby eksperymenty tam prowadzone i wszelkie zmiany nie wpływały na działanie środowiska produkcyjnego.\nProdukcja powinna być maksymalnie izolowana oraz aktualizowana tylko po testach przeprowadzanych na klastrze nieprodukcyjnym.\nW tym układzie zalecany jest już GitOps, przynajmniej dla klastra produkcyjnego. To może być dobry wstęp do pełnego GitOpsa, ale równie dobrze klaster testowy może mieć poluzowane reguły dostępu umożliwiające swobodne eksperymentowanie ze zmianami.\nDwa klastry to już całkiem niezłe rozwiązanie, ale można wciąż lepiej i bezpieczniej!\nDedykowane usługi Szczęśliwi ci którzy mogą w całości operować na chmurze publicznej, bowiem tam dostępnych jest mnóstwo usług bez konieczności zarządzania nimi. Ci którzy mają do dyspozycji tylko własne serwery na środowiskach on-prem stają przed kilkoma dylematami:\nGdzie przechowywać obrazy kontenerów? Gdzie wysyłać Logi i w jaki sposób je przeglądać? Jaki serwer git przeznaczyć na repozytoria aplikacji oraz dedykowane dla podejścia GitOps? Skąd podłączać wolumeny dla aplikacji stanowych? Często okazuje się, że brakuje w organizacji dedykowanych usług i konieczne jest postawienie ich od zera. Wtedy dedykowany klaster na te usługi może być bardzo dobrym rozwiązaniem. Za pomocą operatorów łatwo można postawić rejestr na obrazy, cały stack monitoringu i logowania, storage czy serwery git.\nZe względu na krytyczność takiego klastra musi on być otoczony szczególną opieką, gdyż od dostępności serwisów na nim chodzących zależy działanie pozostałych środowisk.To jest największe wyzwanie i też największy nakład pracy.\nTaki klaster jest bardzo przydatny i jeśli jest on dobrze zaprojektowany oraz odpowiednio zarządzany może sprawić, że w Kubernetes na środowisku on-prem może być równie dobry jak w chmurze.\nKlaster na dane I znowu przypadek kiedy potrzebujemy dedykowanego klastra na dane dotyczy właściwie tylko środowisk on-prem. U dostawców chmury publicznej zamówienie wolumenu na dane to kwestia jednego żądania API i oczywiście płacenia za to czasem nawet słonych kwot.\nAle wracając do dedykowanego klastra to ma on pewne szczególne cechy. Przede wszystkim ze względu na potrzebę udostępniania danych składa się on głównie z węzłów zawierających po kilka dysków. Te w normalnych warunkach, na zwykłych klastrach nie są tak krytyczny, ponieważ węzły w tradycyjnych klastrach przechowują dane głównie tymczasowo.\nOczywiście jeśli masz szczęście to może nie być potrzebny taki klaster jeśli w twoim środowisku istnieje już dedykowane rozwiązania sprzętowe z odpowiednimi sterownikami CSI dla kubernetesa. Przewagą dedykowanego klastra może być jego uniwersalność, ponieważ może on udostępniać aplikacjom i usługom nie tylko storage blokowy, ale też system plików po NFS czy storage obiektowy kompatybilny z S3.\nIle sobie drogi Panie/droga Pani zażyczy Dla naprawdę dużych i krytycznych środowisk potrzeba czasem o wiele, wiele więcej klastrów niż do tej pory wymieniłem. I jest to niezależne od tego czy uruchamiasz to w całości w chmurze, na on–prem czy hybrydowo.\nMoże się okazać że środowisk nieprodukcyjnych może być kilka, kilkanaście lub nawet kilkaset. Każde z nich może być zarządzane przez oddzielne zespoły lub też centralnie przez predefiniowane zestawy konfiguracji wykorzystując Terraform lub Crossplane.\nMogą również istnieć klastry tymczasowe tworzone na żądanie w ramach różnego rodzaju testów w tym tych sprawdzających nowe wersje kubernetesa i jego funkcjonalności.\nCiekawiej wygląda sprawa środowiska produkcyjnego, ponieważ może ono używać więcej niż jednego klastra. Jak wspomniałem na wstępie takie klastry mogą być utworzone u tego samego dostawcy chmury, u różnych i w oddzielnych geograficznie lokalizacjach.\nW przypadku tak dużych środowisk konieczne jest już elastyczne zarządzanie klastrami co oznacza dla środowisk on–prem bazowanie na pewnym API do provisioningu (np. vSphere lub OpenStack) lub sprytne ogarnięcie tego na bare–metal (no bo czy na pewno potrzebujesz wirtualizacji?).\nNo i na koniec dla formalności wspomnę, że tutaj GitOps jest standardem i bez niego nie wyobrażam sobie sprawnego zarządzania taką liczbą klastrów.\nLiczę, że zainteresowałem Cię tematem i kolejnym razem przy projektowaniu środowiska będziesz już bardziej świadomie dobierał układ klastrów do wymagań projektu oraz oczywiście budżetu.\n","tags":["cloud","containers","devops","docker","kubernetes","onprem"],"title":"Newsletter #86 - Ile klastrów tak naprawdę potrzebujesz?"},{"categories":["newsletter"],"date":"October 31, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/85/","section":"newsletter-archive","summary":"No i koniec tego dobrego - wracam z nowymi siłami i energią do pracy.\nMiałem trochę czasu na przemyślenie kilku ważnych dla mnie rzeczy czego efektem są poważne zmiany. O nich dzisiaj chcę Ci opowiedzieć.\nZmiany są potrzebne Podobno wielu ludzi boi się zmian. Być może stan “jest mi tu dobrze więc po co zmieniać” lub “jeśli nie jest zepsute nie ruszaj” jest nam bardziej naturalny. Natura chce, abyśmy oszczędzali energię na wypadek gdyby trzeba było uciekać przed tygrysem, mamutem czy innymi zagrożeniami. Niestety nasz mózg nie wie, że wraz ze zdobyczami cywilizacyjnymi zniknęły te zagrożenia, a nawet niektóre drapieżniki wymarły.\nNa szczęście dla nas wszystkich trwanie w jednym miejscu może być wręcz nudne. Dlatego jako społeczeństwo dokonujemy postępu, bo duża część z nas nie akceptuje obecnego stanu rzeczy, otaczającego nas świata czy chociażby wciąż wywalających się aplikacji na produkcji 🙂 I bardzo dobrze! To pobudza zmiany i eksperymenty. Dzięki nieustannym próbom zmiany, sprawdzaniu ich efektów, dostosowywaniu i uczeniu się na błędach (czyli de facto stosowanie cyklu Deminga) rozwijamy nie tylko technologie, ale też zmieniamy nasze myślenie.\nTakie podejście do uczenia się w cyklach często nazywamy małymi krokami do dużej zmiany. I to wszystko jest i proste i trudne zarazem. Proste, bo wystarczy zastosować, a trudne, bo trzeba walczyć z tą wewnętrzną inercją i strachem przed nieznanym.\nA jak zacząć? To zależy. Tu wchodzi w grę wewnętrzna motywacja, a czasem wręcz zmuszenie się do wykonania pierwszego kroku. U mnie działa wewnętrzna motywacja, bo nie mogę usiedzieć na miejscu nie myśląc o usprawnianiu czegoś, uczeniu się i przygotowywaniu materiałów dla moich odbiorców. Ale u innych motywacja może być inna jak np. chęć poprawy sytuacji życiowej, udowodnienia czegoś sobie i innym, ciekawość lub podniesienie statusu społecznego. Cokolwiek działa i jest zakorzenione głębiej niż tylko proste “powinienem/muszę/byłoby najlepiej gdyby” należy wykorzystać właśnie do swojego rozwoju.\nJeśli czytasz tą wiadomość to znaczy, że szukasz inspiracji do zmian. To dobrze, bo po to go piszę. Ale trochę się rzeczy zmieni, bo po to zrobiłem tą długą przerwę, aby przemyśleć kilka spraw i dokonać pewnych korekt.\nCo się zmieni u mnie Przede wszystkim dziękuję Ci jeśli wypełniłeś ankietę, którą wysłałem ostatnio i tym, którzy wyrazili chęć wkrótce prześlę informację o możliwości spotkania online ze mną w formie 1:1.\nWyniki tej ankiety oraz obserwacje z ostatniej sprzedaży kursu dały mi materiał do przemyśleń. Miałem na nie sporo czasu czego wynikiem są zmiany, które wkrótce zacznę wprowadzać do mojej działalności. Zauważysz je w najbliższych tygodniach, ale pragnę Cię uspokoić - newsletter zostaje i będzie on wydawany co tydzień.\nZmiany, które wprowadzę będą zgodne z następującym podejściem:\nBędę tworzył treści, które sprawiają mi satysfakcję - do tej pory bywało, że robiłem projekty, szkolenia i treści, które mi jej nie przynosiły Będę chciał wykorzystać moje doświadczenie - nie będę zatem zabierał się za tematy, które mi są zupełnie obce (czyli np. AI) Będę skupiał się na praktycznych aspektach, które ułatwiają pracę ludzi z branży DevOps Będę dostarczał treści, produkty i usługi głównie dla ludzi już z pewnym doświadczeniem A co konkretnie się zmieni? Nie zdradzę teraz wszystkiego, ale planuję między innymi:\nPowrócić do tworzenia podcastów Powrócić do regularnego publikowania wideo na YouTube Zacząć prowadzić regularne warsztaty online Zacząć regularnie publikować posty z opisem strategii oraz rozwiązań złożonych problemów Zatem jeśli:\n-\u0026gt; już przeżyłeś efekt Dunninga-Krugera\n-\u0026gt; szukasz nie tylko narzędzi, ale też strategii\n-\u0026gt; dążysz do mistrzostwa i chcesz być cenionym ekspertem\n-\u0026gt; przekonałeś się, że nie ma dróg na skróty i nic nie zastąpi ciężkiej pracy\nto zostając ze mną w tym newsletterze, śledząc mnie na kontach social media (głównie YouTube, LinkedIn i Instagram) i uczestnicząc w przygotowanych przeze mnie wydarzeniach będziesz na naprawdę dobrej drodze do rozwoju Twojej kariery.\nDzięki za przeczytanie moich przemyśleń i za dotychczasową obecność!\nJa tymczasem zakasam rękawy i zabieram się do ciężkiej pracy, aby dowieźć to co obiecałem 🙂\n","tags":["biznes","cloud","containers","devops","edukacja","kubernetes","kurs","rozwój","rozwój-osobisty"],"title":"Newsletter #85 - Zmiany,  zmiany,  zmiany"},{"categories":["newsletter"],"date":"August 29, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/83/","section":"newsletter-archive","summary":"Ale się porobiło! Może nie jest to pierwszy, ani ostatni raz, ale HashiCorp sporo namieszał swoją ostatnią decyzję o zmianie licencji dla projektu Terraform.\nPrzyjrzyjmy się temu bliżej, bo to może mieć duży wpływ na to jak będziemy w przyszłości zarządzać naszymi środowiskami.\nCzym jest HashiCorp HashiCorp to firma założona w 2012 przez dwóch pasjonatów (Mitchell Hashimoto i Armon Dadgar), która utworzyła wiele fantastycznych projektów ułatwiających pracę ze środowiskami chmurowymi, kontenerowymi i nie tylko.\nDla mnie najważniejsze ich projekty to:\nVagrant - pierwszy ich projekt, zarządza deweloperskimi środowiskami lokalnymi głównie przy użyciu wirtualnych maszyn Nomad - niszowy, ale prosty konkurent Kubernetesa Vault - kombajn do zapewnienia bezpieczeństwa danych, świetnie działa z Kubernetes (jest o tym w moim kursie!) Terraform - narzędzie do zarządzanie środowiskami w stylu Infrastructure as Code Ale to nie tylko darmowe projekty open source - to też produkty i jednocześnie przyczyna całego zamieszania.\nProdukty to często te projekty wzbogacone o dodatkowe, enterprise’owe funkcje i sprzedawane ze wsparciem głównie dużym korporacjom. Mogą być one instalowane lokalnie lub używane w modelu SaaS jako grupa produktów HCP.\nTo co jest tu najważniejsze to fakt, iż projekty HashiCorp były w dużej mierze pisane przez społeczność - entuzjastów wolnego oprogramowania. Firmie udało się utworzyć i skutecznie wspierać takich developerów przez co ich projekty niesamowicie szybko się rozwijały i zyskały olbrzymią popularność.\nNo i ta społeczność wyraziła ostatnio duże niezadowolenie z decyzji HashiCorp.\nWiększość funkcji za darmo - jak to możliwe? Zastanawiało Cię dlaczego niemal wszyscy używają projektów HashiCorp za darmo i niewiele osób za to płaci? Możliwe jednak , że Twoja firma posiada jakieś ich produkty. No właśnie - firmy.\nHashiCorp dostarcza 99% funkcji za darmo, a za ten dodatkowy 1% i dedykowane wsparcie płacą naprawdę duże firmy. To nie są kwoty rzędu kilkuset dolarów, a raczej liczone w grubych tysiącach. Wszyscy znają ich projekty i łatwiej jest dotrzeć do dużych firm z pokaźnymi budżetami.\nBiznes to biznes i sytuacja się trochę komplikuje jeśli akcjonariusze (HashiCorp jest notowany na giełdzie) domagają się zysków. Prawda jest bardzo brutalna - za gwiazdki na GitHubie nie zapłacisz pracownikom i nie wypłacisz też dywidendy.\nStąd coraz większy nacisk na firmę, aby zwiększyła swoje przychody i tutaj dochodzimy do tego całego zamieszania.\nKontrowersyjna decyzja HashiCorp ogłosił niedawno, że zmieniają licencje dla wszystkich swoich produktów z Mozilla Public License v2.0 na twór zwany Business Source License.\nW skrócie - zabezpieczają się oni przed budowaniem produktów na podstawie ich projektów. Widzą bowiem, że istnieją firmy takie jak polski startup Spacelift, które zbudowały biznes na popularności narzędzi takich jak Terraform. Możliwe nawet, że produkty te są w niektórych wypadkach lepsze od odpowiedników od HashiCorp. I to się mogło menedżerom w HashiCorp niespodobać.\nNikt chyba nie spodziewał się aż takiej reakcji społeczności (inspirowanej przez te zagrożone firmy), która wzięła sprawy w swoje ręce.\nDwa Terraformy Powstała fundacja OpenTF, która chce uchronić Terraform. W zasadzie to wkrótce utworzony zostanie drugi projekt Terraform o nazwie OpenTF właśnie.\nNa stronie piszą, że liczą jeszcze na zmianę decyzji przez HashiCorp, ale według mnie to są tylko mrzonki. Sytuacja może przypominać tą z Jenkinsem. Czy wiesz, że kiedyś był projekt Hudson, a Jenkins powstał jako fork w odpowiedzi na zmianę licencji przez Oracle? Ostatecznie projekt umarł, a jego fork przerósł jego popularność i prawie nikt nie pamięta już pierwowzoru.\nCzy to samo może spotkać Terraform?\nCzy to początek końca HashiCorp Terraform? Osobiście uważam, że szanse są znikome. Aczkolwiek o wszystkim zdecyduje społeczność, bo to ona w dużej mierze stoi za sukcesem projektów HashiCorp. W przypadku takiego Terraform to zewnętrzni developerzy dostarczyli kod do providerów obsługujących większość dostawców chmury publicznej. Ich odwrót w stronę projektu OpenTF może dać się porządnie we znaki firmie HashiCorp.\nMoże to czas wziąć popcorn i przyglądać się dalej tej sytuacji, ale to też zależy od Twojego podejścia do tego tematu.\nCo to zamieszanie oznacza dla Ciebie Jeśli jesteś entuzjastą oprogramowania open source (wiesz - takiego prawdziwego na dobrej licencji, a nie tylko darmowego) to pewnie “nowy” Terraform (OpenTF) wkrótce zastąpi u Ciebie “oryginalny” Terraform. Szczególnie jeśli nie używasz produktów, a budujesz samodzielnie rozwiązania z dostępnego softu.\nJeśli nie przywiązujesz wagi do tego na jakiej licencji są wydawane Twoje narzędzia to prawdopodobnie nie będzie to dla Ciebie większa różnica i pozostaniesz przy Terraform od HashiCorp. Podobnie było w przypadku Dockera - jest sporo alternatyw (np. Podman od Red Hata), a większość pewnie używa oryginalnego softu od Docker Inc.\nPoruszenie w społeczności pokazało jednak bardzo ważną rzecz. Terraform jest baaardzo popularny i szeroko używany. To jest standard i niekwestionowany lider w zarządzaniu środowiskami dla aplikacji.\nZ tego względu w moich planach jest miejsce na ciekawe treści z tym związane. Możliwe, że będą one dotyczyć zarówno Terraform jak i OpenTF.\n","tags":["cloud","containers","devops","docker","hashicorp","terraform","vault"],"title":"Newsletter #83 - Jak HashiCorp namieszał z Terraform"},{"categories":["pl"],"date":"August 15, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/pl/jak-dobrze-uczyc-o-technologiach/","section":"pl","summary":"Najlepiej uczyć się ucząc innych. Po wielu latach prowadzenia szkoleń mogę to potwierdzić. To, że coś umiesz, ale dodatkowo potrafisz to przystępnie wytłumaczyć świadczy, że masz to dobrze rozgryzione i ułożone w głowie.\nPrzygotowałem dla Ciebie listę dobrych praktyk jeśli sam będziesz przygotowywać materiały na szkolenie lub warsztat. Możesz też wykorzystać jako wskazówki do szukania dobrych materiałów do własnej edukacji (i niekoniecznie moich kursów czy szkoleń!). Poniższa lista powstała jako wynik wieloletniej praktyki na salach szkoleniowych, sporej ilości błędów, wielu eksperymentów, stresu i niepewności, ale też osobistej pasji do rozwoju.\nNawet jeśli nie przeczytasz tej całej listy to zapamiętaj, że czasem to nie TY stanowisz problem - często to nieodpowiedni sposób przekazywania wiedzy, przygotowane materiały lub nawet nauczyciel/trener.\nPowiedz do czego coś jest, a nie tylko jak działa Mamy pewnie różne doświadczenia ze szkołą, ale ja pamiętam nauczycieli rzemieślników, którzy przerabiali materiał bez tłumaczenia po co dana rzecz jest i jakie ma praktyczne zastosowanie. Ostatnio trafiłem na bardzo ciekawe materiały na YouTube tłumaczące do czego są używane pochodne i całki. Nie pamiętam, aby ktokolwiek podczas mojej edukacji powiedział o ich zastosowaniu - każdy skupiał się na zakuwaniu zasad i przygotowaniu do egzaminów. Nasz mózg może się buntować przeciwko takiemu wkuwaniu i zdecydowanie wolimy jak widzimy w tym sens. Mówię tutaj o edukacji pozaszkolnej, gdzie nie musisz zdawać egzaminów, a rozwiązywać realne problemy. Dlatego tłumacz zastosowanie danej technologii, bo my dorośli nie lubimy być traktowani jak dzieci, a nawet te nie lubią wkuwać bez widzenia sensu. Nie chcemy być bezmyślnymi trybikami - jesteśmy zdecydowanie bardziej zaawansowanymi istotami i zasługujemy na lepsze wyjaśnienia.\nTo jest fundament, który stosuję w moich kursach. Jestem wyczulony na bezsensowne technologie/techniki, które poznajemy i później używamy w ramach przysłowiowego szukania gwoździ znając jak obsługiwać młotek.\nUcz przez palce Chodzi głównie o technologie z obszaru IT (aczkolwiek ma też pewnie zastosowanie m.in. przy garncarstwie). Teoria jest łatwiejsza do przekazania, bo nie musisz przygotować zadań praktycznych. To jest jedna z moich ulubionych części, bo mi pozwala jeszcze dokładniej poznać dany obszar i pokazać uczestnikom realne zastosowanie. Nie łudź się, że przez kilka ćwiczeń ktoś stanie się biegły i pewny w danym obszarze. Zadaniem ćwiczeń jest pokonanie pierwszego wewnętrznego oporu. Pamiętam, że po pierwszym kontakcie z AWS dobrych parę lat temu kolejne poznawanie przyszło mi łatwiej.\nZaakceptowanie tego jak działamy zdejmuje wielki ciężar z prowadzącego szkolenie, ale też z uczestników. Jesteś często po to, aby ułatwić przejście przez kilka pierwszych progów, rozwiać początkowe obawy i “rozpędzić” w dalszym poszukiwaniu. To dlatego mi często przygotowanie szkolenia czy kursu zajmuje o wiele dłużej, bo nie wyobrażam sobie ich bez dobrej części praktycznej.\n“Możesz konia doprowadzić do wodopoju…” .. lecz pić za niego nie będziesz. To fundamentalna zasada, która zdejmuje z trenerów odpowiedzialność z wysiłku niezbędnego do przyswojenia materiału. Tak, możesz się produkować jak szalony, a nikogo nie zmusisz nawet do słuchania. Tym się odróżnia edukacja dorosłych od dzieci, że ci pierwsi są odpowiedzialni za swoje życie i tym jak nim kierują. Ja na sali szkoleniowej miałem osoby, które jakby były “za karę” na szkoleniu i dopóki nie przeszkadzały mi w prowadzeniu to nie czułem się w obowiązku zbawiania czy ewangelizowania ich na siłę. Może nie był to ten czas dla nich, może przechodzili trudne chwile w swoim życiu, może faktycznie zostali wysłani przez menedżera, aby się wyedukować pod jakiś nadchodzący projekt. I coś co jest emocjonalnie cięższe do udźwignięcia to fakt, że po prostu pewnej grupie osób nie przypadnie Twój sposób prowadzenia, Twoje materiały, albo… Twoja osoba (np. tembr głosu lub zbyt głośne mówienie - mój głos jest dość donośny). No cóż, bywa i z punktu racjonalnego to nic strasznego to może czasem “ukłuć” wewnętrznie, bo w końcu jesteśmy istotami emocjonalnymi.\nTo co zależy od Ciebie to odpowiednie przygotowanie siebie (również mentalne), przygotowanie dobrych materiałów i przekazanie swojej wiedzy najlepiej jak potrafisz. To czy trafi to na podatny grunt i jak to ktoś wykorzysta to już inna sprawa. Rób swoje i rób to dobrze.\nPozbądź się pokusy nauczania wszystkiego To jest powiązane z poprzednim punktem, bo posiadając wiedzę w głowie wraz z ułożonym sposobem jej przekazywania może Ci się wydawać, że dasz radę przekazać ją w całości. Masz rację - wydaje Ci się. Fizycznie jesteśmy ograniczeni do przyswajania wiedzy. Fakt, że są geniusze pochłaniający wszystko kilkukrotnie szybciej nie znaczy, że znajdziesz ich u siebie na widowni. To nie oznacza jednak, że masz podchodzić luzacko do budowania nowych umiejętności u Twoich kursantów. Każdy z nas jest inny i ma inne doświadczenia zawodowe czy zainteresowania. W idealnym świecie każdy przyswaja wszystko. Znamy osoby, które w szkole pochłaniały materiał. Ja zaliczałem się do tych co wolały skupiać swoją energię tylko na pewne tematy i być może dzięki temu jestem tu gdzie jestem. Świadomy tego tak prowadzę szkolenia, aby poruszać temat, który naprawdę jest interesujący dla uczestników. Podobnie w moim najnowszym kursie na początku mówię o tym, aby wybrać tylko to co najbardziej kogoś frapuje czy interesuje. Na resztę materiału może przyjść czas później albo i wcale. I to też jest OK.\nRysuj nawet jak nie umiesz Według różnych publikacji w kontekście uczenia się aż 65% z nas to wzrokowcy. Stąd nieocenione są różnego rodzaju pomoce trafiające do nas przez zmysł wzroku. Znam osoby, które nie są wzrokowcami i wystarcza im dokładne opowiadanie, ale spotkałem się z publikacjami mówiącymi, że nawet dla nich korzystne są wszelkiego rodzaju rysunki i diagramy. Ja osobiście uważam się za kiepskiego rysownika, ale jest i tak lepiej niż na początku mojej kariery. Trzymam się tylko tych trzech zasad przy tworzeniu diagramów przy tłumaczeniu:\nRysuję duże elementy i używam dużych napisów. Przydaje się to do ich uzupełniania w trakcie lub gestykulowania wokół. Używam kilku kolorów, ale ograniczam się do 3, góra 4. Więcej nie ma potrzeby. Często poszczególne kolory przeznaczam do elementów z danego obszaru (np. połączenia sieciowe). Używam tylko podstawowych kształtów - prostokąt, koło, trójkąt, walec i jak poszaleję to jakiś romb. Do tego strzałki i gotowe. Nie musi być pięknie, a tylko funkcjonalnie. Polecam narzędzie Excalidraw - świetnie się sprawdza głównie przy szkoleniach zdalnych. Moje slajdy w kursach nie są piękne, ale są proste, bo mają na celu pomóc w zrozumieniu tematu. Uważam, że piękne diagramy wyglądają na prezentacjach lub w materiałach sprzedażowych. Jest to szczególnie jeśli musisz ich stworzyć do kursu nie kilkanaście, a kilkaset jak w moim przypadku ostatnio.\nZainteresuj Zakładam, że nie znalazłeś się za karę w sali z ludźmi, którzy chcą się od Ciebie czegoś nauczyć lub nie tworzysz kursu pod przymusem. Masz coś ciekawego do opowiedzenia o danym temacie i być może nawet Cię on bardzo interesuje. Poza suchą wiedzą postaraj się przekazać również swój entuzjazm. Przyznam, że to nie jest łatwe. Szczególnie na szkoleniach na żywo, gdzie w grę wchodzi Twój nastrój i różne rzeczy dziejące się w Twoim życiu. Jeśli uda Ci się wchodząc na salę przybrać rolę zaangażowanego nauczyciela to zauważysz to po zaangażowaniu ludzi (pamiętaj jednak, że nie wszystkich) jak i również Twojej satysfakcji z takiego szkolenia. Ja na sali staram się ciekawie opowiadać i dorzucam czasem moje poczucie humoru. Działa to całkiem nieźle za wyjątkiem części po obiedzie - wtedy godzę się z faktem ogólnego spowolnienia i spadku energii. Łatwiej jest na nagraniach do kursu - tam mogę powtarzać ujęcia i przygotować dokładnie co oraz w jaki sposób chcę powiedzieć.\nNie przynudzaj tylko krótko i treściwie Pamiętam jak zaczynałem to koniecznie chciałem opowiedzieć wszystko w najdrobniejszych szczegółach, bo może znaleźć się ktoś komu się to przyda. Takie zarzucanie informacjami powoduje wyłączenie uczestników. Przestają być oni zainteresowani tym co mówisz. Wciąż się na tym łapię, że chcę mówić o szczegółach i dlatego na starcie szkoleń na żywo proszę uczestników, aby mi przerywali jeśli przynudzam. Może to wpływ krótkich treści dostępnych w social media, a może po prostu od zawsze tak mieliśmy. Chcemy dużo konkretów w krótkim czasie. Dlatego dobre szkolenie i kursy poznaje się nie po tym ile trwają, ale ile w tym czasie znajdziesz przydatnych i konkretnych treści. Dla przykładu w moim ostatnim kursie moje lekcje trwają od kilku do maksymalnie kilkunastu minut. Te ostatnie są dłuższe, bo nie mogłem podzielić danego tematu na mniejsze. Liczy się, aby uczestnik mógł znaleźć tam wartościowe informacje. W końcu jeśli podjąłeś się przygotowania szkolenia lub kursu to po to, aby zsyntezować wiedzę, dodać swoje doświadczenie i przekazać ją w przystępny sposób oszczędzając czas uczestników. Dlatego nie przynudzaj i dostarczaj wartościowe konkrety.\nNiezależnie czy będziesz kiedyś na moim szkoleniu czy kupisz jakikolwiek kurs ode mnie pamiętaj, że bardzo dużo zależy od jakości materiału i prowadzącego. A jeśli interesuje Cię obszar technologii Kubernetes to zachęcam Cię do sprawdzenia mojego kursu “Kubernetes po polsku”.\n","tags":["biznes","devops","edukacja","jenkins","kariera","kubernetes","kurs","rozwój","rozwój-osobisty"],"title":"Jak dobrze uczyć o technologiach"},{"categories":["newsletter"],"date":"August 8, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/81/","section":"newsletter-archive","summary":"W końcu. To już koniec. Udało się.\nPo niemalże pół roku od rozpoczęcia przedsprzedaży ukończyć w całości kurs “Kubernetes po polsku”.\nW środę tydzień temu opublikowałem część PRO dla szczęśliwców, którzy mi zaufali i kupili go w przedsprzedaży. Inni będą mogli do nich dołączyć już 6 września podczas jego oficjalnej premiery.\nA dzisiaj podzielę się kilka spostrzeżeniami po pół roku pracy nad kursem.\nA na co to komu? To jest dobre pytanie, na które mam taką oto odpowiedź. Wiem, że Kubernetes to dość niszowy temat w IT, nie jest już tak modny jak kiedyś - stał się po prostu standardem. Są tacy co już go używają od dawna, inni zastali go w projekcie, a znowu inni są na początku drogi.\nStąd są to dwa oddzielne kursy - podstawy nazwałem fundamentami, a część zaawansowaną po prostu PRO.\nZatem są trzy grupy odbiorców:\nPoczątkujący- osoby, które nie miały jeszcze styczności z Kubernetesem, a wiedzą, że będzie to wymagane przy projekcie lub mądrze planują swoją karierę. Dla nich przygotowałem fundamenty.\nPoszukujący- użytkownicy, których teraz większość spotykam na moich tradycyjnych szkoleniach. To osoby pracujące z Kubernetesem, ale już w przygotowany przez kogoś sposób. Wielokrotnie na takich szkoleniach dowiadują się jak działa ten Kubernetes i jak go poprawnie używać. Często potem oszczędzają mnóstwo czasu, poprawiają swoje metody pracy i optymalizują kosztowo swoje środowiska.\nDla nich jest wiedza z fundamentów i materiał PRO jeśli chcą dalej poszerzyć swoje horyzonty.\nProfesjonaliści - osoby pracujące z Kubernetesem już dłużej. Możliwe, że oglądały mój pierwszy, prosty kurs i czują niedosyt. To dla nich przygotowałem część PRO z unikalnymi materiałami, które ciężko znaleźć w sieci. Część PRO skupia się na produkcyjnych praktykach i lepszym wykorzystaniu tego co ma Kubernetes do zaoferowania. Dzięki moim lekcjom i labom będą mogły one między innymi\nUżywać reguł RBAC dla dostępu aplikacji i użytkowników do klastra Efektywnie zarządzać zasobami klastra Zarządzać dystrybucją podów wewnątrz klastra Używać zaawansowanych metod zarządzania wolumenami dla aplikacji stanowych Zbudować własny klaster on-prem od podstaw Czy było warto? Poświęciłem 6 miesięcy i prawie pół tysiąca godzin pracy. Poznałem ciekawe narzędzia, poznałem bardziej siebie i ogólnie sporo się nauczyłem. Dla tych rzeczy przynajmniej było warto.\nCo do sukcesu samego kursu to wciąż nie wiem. Okaże się po premierze czy faktycznie odpowiada on na realne zapotrzebowanie rynku. Ale kto nie ryzykuje ten się nie uczy i nie je sernika.\nCo było najtrudniejsze w przygotowaniu kursu? Bez wątpienia motywowanie się do pracy. Pierwsza część kursu to było w miarę ok, ale przy drugiej to już było duże wyzwanie. Wstawanie rano z myślą, że tyle jeszcze mam do przygotowania. A nie zawsze jest nastrój i chęci.\nTrudne też było “ściskanie” treści, aby nie zrobić kursu kilkudziesięciu godzin nudnych lekcji, a wydobyć to co najważniejsze. To przez taką syntezę wiedzy to tak długo mi zajęło. Myślę, że rezultat jest zadowalający.\nNo właśnie, co do tego zadowolenia. Kolejna wewnętrzna walka, którą odbywałem niemalże codziennie to odpowiedź na pytanie mojego wewnętrznego perfekcjonisty - “czy to jest wystarczająco dobre?”. Przez kilka wątpliwości usunąłem kilka pierwotnie planowanych lekcji, bo nie odpowiadały moim standardom i nie dawały odpowiedniej wartości.\nKiedy wysyłałem maile o kolejnych opóźnieniach to również czułem ucisk w żołądku, bo w końcu nie wywiązałem się z mojej obietnicy. Na szczęście odbiorcy byli wyrozumiali za co im bardzo dziękuję!\nNajciekawsze fakty Oto kilka interesujących faktów z produkcji kursu:\nPierwotnie miał być jeden kurs, ale będą dwa oddzielne odpowiadające na różne potrzeby - to te wspomniane wcześniej fundamenty i PRO Pierwotnie nazwa kursu miała brzmieć inaczej - mam nawet wykupione domeny! Jednak zostałem przy tej prostej, gdzie “po polsku” nie oznacza tylko, że jest po polsku. Owszem - jest on dedykowany polskiemu IT, ale oznacza również, że łatwo wyjaśnia skomplikowane niuanse technologiczne - to bardziej z powiedzenia “Powiedz mi to jeszcze raz, ale tak po polsku” Nagrałem łącznie 113 lekcji wideo z ponad 300 diagramami o łącznej długości 12 godzin Przygotowałem 32 laby w postaci wideo KROK PO KROKU o łącznej długości 8 godzin Część PRO jest niemalże dwukrotnie dłuższa, bo dłużej zajmuje też tłumaczenie złożonych części Kubernetesa Pomimo większej złożoności top przygotowanie części PRO zajęło mniej więcej tyle samo czasu co części o fundamentach - to dlatego, że zoptymalizowałem w międzyczasie proces przygotowania. To była też dla mnie wspaniała lekcja! A co jest najważniejsze przy robieniu materiałów edukacyjnych? Chętnie o tym napiszę i zostawię to na przyszłotygodniowy newsletter :)\nPolecam zapisanie się na listę dostępną na stronie kursu - dostaniesz informacje o premierze i bezpłatną mapę Kubernetes!\n","tags":["biznes","cloud","containers","devops","docker","edukacja","kubernetes","kurs","rozwój","rozwój-osobisty"],"title":"Newsletter #81 - Skończyłem"},{"categories":["newsletter"],"date":"July 25, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/80/","section":"newsletter-archive","summary":"Może też tak masz, że nie wiesz gdzie ucieka Ci ten czas. W końcu jeszcze nie tak dawno skończyłeś szkołę średnią, a tu dzieci sąsiadów mówią do Ciebie dzień dobry i zwracają się per Pan.\nCzas to jedyna rzecz, której nie da się kupić. Jedynie co możemy to dobrze go rozdzielać na ważne rzeczy. A nie jest to niestety łatwe.\nPożeracze czasu Kiedyś Reed Hastings, CEO Netflixa, zapytany co jest ich największą konkurencją odpowiedział, że… sen. Jest mnóstwo usług, które rywalizują o naszą uwagę, bo to realnie przekłada się na ich zysk.\nDlatego z tyloma pokusami może być naprawdę ciężko zrobić coś konkretnego. Do tego mnóstwo powiadomień z naszych telefonów z appek, które też walczą o uwagę.\nZ tego powodu jakiś czas temu przestałem zaglądać na Facebooka czy Instagrama. To ostatnie szczególnie skutecznie przeszkadza w realizacji mojego planu - wydania mojego kursu. Ale wkrótce tam wrócę z ciekawymi i wartościowymi materiałami - cierpliwości :)\nDuże cele = dużo czasu W sumie to da się płynąć z prądem, bo to łatwe i przyjemne - w końcu zostało to zaprojektowane przez grupę psychologów behawioralnych na podstawie dostępnych badań. Jesteśmy naprawdę nieźle rozpracowani i jeśli mówisz, że to na Ciebie nie działa to paradoksalnie może działać nawet bardziej (też kiedyś tak myślałem o sobie w stosunku do reklam).\nJeśli jednak coś Cię “swędzi” w środku i masz wyrzuty, że nie zajmujesz się ważnym dla Ciebie projektem to może tak jak ja potrzebujesz potrzebujesz podjąć kolejną próbę. Moje doświadczenia z ostatnich miesięcy uświadomiły mi, że duże projekty wymagają duuużo czasu. Nie da się zrobić czegoś naprawdę wartościowego w dzień, tydzień czy nawet miesiąc.\nTaki kurs na przykład, który tworzę zajął mi obecnie mi ponad 420 godzin(konkretnej pracy kiedy siedzę i tworzę). Skąd to wiem?\nLiczby Ci prawdę powiedzą Od kilku miesięcy loguję każdą godzinę pracy w narzędziu Trackr. To dopiero uświadomiło jak ważna jest każda godzina, której NIE przeznaczam na mój projekt. Kiedyś mogłem się oszukiwać, że mam inne ważne zajęcia, ale teraz nie mogę się kłócić z własnymi danymi.\n“Prawda Cię wyzwoli, ale najpierw wkurzy” - w moim wypadku raczej zmusiła mnie do zmiany podejścia. Do tej pory odmówiłem już prowadzenia wielu szkoleń i odrzuciłem kilka propozycji współpracy. Sprawdziłem to na przykładzie już prowadzonych w trakcie, że te godziny oddalają mnie od ukończenia realizacji mojego projektu. Jednocześnie doświadczam na własnej skórze efektu kosztu utraconych korzyści “ opportunity cost”) . Teraz muszę świadomie walczyć z poczuciem straty kalkulując, że takie 3 dni szkolenia to realne 18 godzin (rzadko loguję więcej niż 6 godzin realnej pracy dziennie), które mógłbym użyć do popchnięcia projektu. Nie licząc poszczególnych godzin, które przeciekają przez palce na social media i inne.\nWiele razy już zaczynałem - nadszedł czas, aby zacząć kończyć.\nPisanie newsletterów też loguję - średnio zajmuje mi to 90 minut ciągłej pracy.\n","tags":["biznes","edukacja","kurs","rozwój","rozwój-osobisty"],"title":"Newsletter #80 - Jak nie marnować czasu"},{"categories":["newsletter"],"date":"July 11, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/79/","section":"newsletter-archive","summary":"Nie wiem jak Ciebie, ale mnie zewsząd atakują posty ludzi piszących i nagrywających o AI. Mnóstwo infografik i zestawień promptów do ChatGPT, które na zawsze zmienią to jak pracuję.\nOstatnio przy śniadaniowym oglądaniu YouTube wyskoczyła mi reklama kursu używania ChatGPT, który całkowicie odmieni moje życie i w końcu będzie super (ostatnie sobie dopowiedziałem po sposobie prezentacji).\nJuż kiedyś odnosiłem się do ChatGPT, ale mam nowe przemyślenia z tym związane, którymi chcę się z Tobę podzielić. W zasadzie to są pytania i moje wątpliwości. Tak - biorę pod uwagę, że być może jestem niedoinformowany albo zamknięty na to co znam.\n(UWAGA - poniższe pytania mogą zawierać odrobinę sarkazmu)\nCzy AI wykona za mnie pracę?\nNie mówię tu o utworzeniu strony, napisania kawałka kodu - to w końcu też praca. Chodzi mi o takie niewirtualne rzeczy. Nie będę chciał budować domu, ale jak chcę zrzucić zbędne kilogramy lub pozbyć się ponurych nastrojów to po czyjej stronie to pozostanie? Bo ja bym chciał, aby to było po stronie AI. Nie chcę się męczyć. Dobre rady (i przepisy na diety) były i przed AI.\nTo są trudniejsze i z mojego punktu widzenia o wiele ważniejsze rzeczy.\nCzy AI pomoże w tworzeniu i podtrzymaniu relacji?\nWiele osób zachwyca się zlecaniem pisania maili. To fajne - zawsze uważałem komunikację jako sposób podtrzymywania relacji. Osobiście nie wiem tylko czy chciałbym, aby odpisywał mi automat. To działa może w obsłudze klienta do rozwiązywania problemów i tu widzę duży potencjał.\nWiadomości z klientem, szefem i osobami dla mnie ważnymi wolę pisać samodzielnie. Nie będzie to może tak optymalne, ale osobiste. Może czasem dorzucę coś od siebie z humorem, a czasem dam znać, że dzisiaj nie mam nastroju i szybko załatwię sprawę.\nRelacje były i będą kształtowały nasze codzienne życie chyba najmocniej.\nCzy mogę zaufać wszystkiemu co wytworzy AI?\nPrawa w USA jest bardzo zawiłe i dlatego też wiele firm prawniczych używa ChatGPT do podczas codziennej pracy. Jeden z prawników użył go do stworzenia pozwu. Nic w tym dziwnego, bo jak można maile to pozwy również dać AI do pisania. Ale w tym wypadku ChatGPT podał nieistniejący przypadek, który został wychwycony.\nPewnie na ten jeden są może tysiące prawidłowo wypełnionych, ale jeśli nie jesteś ekspertem to jak wychwycisz pojawiające się błędy mniejsze i większe?\nGoogle oraz cały internet też ma dużo bzdurnych odpowiedzi i karmi tym zwolenników różnych teorii spiskowych, ale czuję, że zaufanie do ChatGPT jest większe niż do pozostałych źródeł, bo to w końcu sztuczna inteligencja.\nCzy to nie jest przypadkiem kolejny hype?\nBył nie tak dawno hype na NFT - to miała być rewolucja w dostarczaniu treści cyfrowych. Na tej rewolucji zarobili Ci co o tym głośno krzyczeli, a teraz już niewiele kto o tym mówi. Był i wciąż jest Bitcoin. Po przekrętach z FTX i problemach kolejnej giełdy kryptowalut Coinbase wciąż nie doczekaliśmy się rewolucji w finansach obiecywanej przez kryptowaluty.\nBitcoin podlega spekulacjom, ale samą technologię Blockchain czeka pewnie jeszcze długa droga i liczę, że coś z tego ciekawego wyjdzie.\nKsiążki o ChatGPT na Amazonie sprzedają się jak szalone, bo każdy chce robić lepiej. Może trzeba przeczekać tych co przeskoczyli z bycia ekspertem od NFT lub kryptowalut na AI, aby skoczyli na coś nowszego?\nCzy AI spowoduje zamęt na rynku pracy?\nTak. Tu nie mam wątpliwości. On już spowodował. Tam gdzie ludzie wykonywali odtwórczą pracę biurową etaty ich zostały zredukowane w ramach ostatnich zwolnień. Podobnie z tłumaczami i grafikami (Photoshop z AI rozwala system).\nJak będzie z programistami i ludźmi od DevOps? Jeszcze nie wiem, ale obserwuję rynek na bieżąco i podejmę też właściwe kroki jeśli coś zauważę.\nNiestety jak nie umiałem gotować tak nie umiem nadal. Nie mam szans na założenie knajpy lub chociażby budki z kebabem. Ostatecznie pozostanie mi wypasanie 🐑🐑🐑 gdzieś w Bieszczadach, bo tu ChatGPT wciąż nie daje rady.\nCałość napisana samodzielnie bez użycia AI.\n","tags":["chatgpt","rozwój"],"title":"Newsletter #79 - Pięć pytań o AI"},{"categories":["newsletter"],"date":"July 5, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/78/","section":"newsletter-archive","summary":"Red Hat po wielu latach zmienia swoje podejście do kodu źródłowego swojego flagowego systemu - Red Hat Enterprise Linux.\nW internetach zaczęło się szczucie na firmę, która pokazała światu, że da się prowadzić dobry biznes, tworzyć dobry produkt i jednocześnie udostępniać jego kod źródłowy totalnie za friko. Co teraz zrobią tysiące firm, które wykorzystywały darmowe odpowiedniki RHELa? Czy to koniec dobrych czasów i przyszedł czas zapłaty?\nDlaczego tak lubimy open source Projekt GNU był stworzony, aby szerzyć kulturę dzielenia się wolnym oprogramowaniem. Jego największym sukcesem jest zdecydowanie kernel Linuksa, który zrewolucjonizował nasz świat - bez niego nie byłoby Androida i usług chmury publicznej w takim kształcie jaki obecnie znamy.\nSukces Linuksa i innych projektów open source (w tym Kubernetes!) jest jednak według mnie dość prozaiczny - taki soft jest za darmo! I stąd to oburzenie, bo jak płacić za open source? W końcu to dostępny kod źródłowy i można go sobie pobrać oraz samodzielnie zbudować.\nTo stara śpiewka o tym, że dlatego wolimy open source. W rzeczywistości używamy takich projektów, bo są za darmo, a nasi pracodawcy lub klienci wolą nie płacić za soft niż płacić.\nJa też lubię jak coś jest za darmo, ale to jest bardziej złożone.\nTrudna strona open source Ci co wypuścili nawet mały kawałek softu na GitHub wiedzą, że nawet w niewielkiej skali utrzymanie tego wymaga sporo pracy. Użytkownicy zgłaszają problemy (najczęściej), usprawnienia w postaci Pull Requestów (rzadziej, ale również wymaga czasu), a zależne biblioteki się zmieniają i twój mały kawałek wymaga często dostosowania.\nJeśli żyjesz w bańce, że wystarczy coś wypuścić i to magiczne “community” będzie dalej to rozwijać to muszę Cię zmartwić. W idealnym świecie być może tak by było, ale przykład Red Hata pokazuje, że to tak nie wygląda.\nFakt, że taki Oracle wziął kod źródłowy, dodał logo i trochę pozmieniał rzeczy w kernelu zachowując kompatybilność nie poprawiło sytuacji.\nRHEL wypracował przez lata jedną kluczową rzecz - kompatybilność z producentami sprzętu i oprogramowania. To wymaga sporo pracy. A do tego jest jeszcze jedna rzecz, za którą firmy płacą. To czas.\nRed Hat utrzymywał stare wersje oprogramowania (jak np. archaiczny Python2.7) przez wiele lat od zaprzestania ich rozwoju. Dzięki temu wiele organizacja mogło odroczyć ryzykowne większe aktualizacje i migracje. To oszczędza naprawdę sporo czasu i pieniędzy.\nA zatem wypracowałeś soft, zachęciłeś producentów sprzętu i innego oprogramowania do testowania oraz certyfikowania na nim, a do tego publikujesz kod źródłowy i patrzysz jak inni tworzą klony Twojego produktu.\nPodobne wyzwanie stanęło przed Elasticsearch, gdy AWS zaczął oferować go jako usługę na swojej chmurze. Dla klientów to fajne, dla tych co inwestują czas swoich pracowników już mniej.\nCzy Red Hat jest tu poszkodowany? Niekoniecznie. Druga strona medalu jest taka, że Red Hat przez długi czas miały naprawdę dobry PR, bo w końcu dzieli się ze społecznością sporą częścią swojej pracy. Przez długi okres czasu myśleli też, że CentOS to świetna okazja, aby przyzwyczaić firmy do standardu RHEL i później podmienić to na subskrypcje RHEL.\nJak się okazało to nie wyszło, a płacić ludziom trzeba. Zatem nowy właściciel zmienia te stare zasady i kod będzie dostępny tylko dla partnerów i klientów. To ostatnie kojarzy mi się już z polityką Microsoft, który swego czasu w okresie boomu open source obiecał udostępnianie kodu Windows dla swoich klientów. Nikt chyba jednak zbudował własnego systemu na tej podstawie.\nCo dalej z darmowym open source Możliwe, że Debian powróci do łask jak to miało w przypadku kontenerów (przypomnę, że większość obrazów oparta jest na Debianie właśnie) albo też Ubuntu jeszcze wzmocni swoją pozycję. W końcu mają swoje wersje PRO ze wsparciem.\nO przyszłość samego open source się nie martwię. Po prostu czas pokazał, że tu nie o darmowość chodzi, a o wspólne korzyści wielu firm. Doskonale to pokazuje jeden z największych projektów, bo obok kernela linuksowego to Kubernetes jest takim projektem.\nTam wszystko się spina, bo są spełnione następujące warunki:\nSą zaangażowane firmy inwestujące sporo czasu swoich pracowników (tak, płacą im za to) Firmy takie przychodzą ze swoimi potrzebami do poszczególnych grup odpowiedzialnych za rozwój danej części projektu (np. Scheduling, networking, cloud) Istnieją też pasjonaci poświęcający swój prywatny czas, uczący się lub dzielący pomysłami Istnieje ciało nadzorujące (komitet sterujący), które mam świadomość, że jest to projekt, z którego budowane są usługi i produkty Sam projekt jest do użycia za darmo dla tych co nie potrzebują wsparcia i mają odpowiednie zasoby do ogarniania większej złożoności Zatem spokojnie, to czas zmian, ale wyjdzie to ostatecznie na dobre.\n","tags":["biznes","opensource","redhat"],"title":"Newsletter #78 - Czy to koniec dobrych czasów dla open source?"},{"categories":["newsletter"],"date":"June 28, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/77/","section":"newsletter-archive","summary":"Podobno wszyscy jesteśmy kiepscy w szacowaniu. I kiepski jestem również i ja. Mój kurs, który przygotowuję od kilku miesięcy ma kolejne opóźnienia (dokładne info wyślę wkrótce do tych co kupili go w przedsprzedaży) i postanowiłem z tej okazji przyjrzeć się bliżej temu zjawisku.\nDlaczego szacowanie jest trudne Przyczyn jest wiele. Często przeszacowujemy naszą wiedzę i podobnie jak w przypadku efektu Dunninga-Krugera wygrywa nasza fałszywa pewność siebie przyprawiona dużą dawką optymizmu.\nSzacowanie jest lepsze jeśli posiadamy więcej prawdziwych informacji. Tak jest w moim wypadku, gdyż nie miałem wystarczających informacji i przyjąłem tylko optymistyczne warianty bez uwzględnienia innych, czasem losowych czynników.\nCo należy uwzględniać przy szacowaniu Głównie to czego nie wiemy i czego oszacować się nie da. Pewien mądry pan - Nassim Taleb - napisał o efekcie czarnego łabędzia i to doskonale pasuje do ostatnich wydarzeń, które wstrząsnęły naszym światem. Mówię tu o pandemii COVID-19 i wojnie w Ukrainie.\nTakie rzeczy zdarzają się bardzo rzadko, ale tak jak awarie na naszych systemach prędzej czy później nastąpią. I wtedy nasze plany muszą być odpowiednio dostosowane.\nW projektach jak mój warto wziąć pod uwagę przypadki losowe takie jak choroby czy też dołki i objawy wypalenia. Nie wiedziałem o tym przed, a teraz będzie to bardzo ważny składnik przy szacowaniu kolejnych prac.\nJak poprawić trafność estymacji Nie mamy wpływu na zdarzenia losowe więc te niezależnie wpływają na nasze plany z pewnym prawdopodobieństwem ich wystąpienia (zależne od naszego stosunku do ryzyka).\nTo na co mamy wpływ to nasza wiedza. Im mamy jej więcej tym szacowania są dokładniejsze. W świecie IT to właśnie odróżnia ludzi na stanowiskach juniorskich od seniorskich. Ci pierwsi są nad wyraz optymistyczni i przeszacowuja swoją wiedzę. Seniorzy czy eksperci widzieli więcej i stąd ich wiedza pozwala im dokładniej określać ramy czasowe projektów. To często jest podważane przez niecierpliwych menedżerów projektów, ale często jest po prostu dokładniejszym określeniem trudnej rzeczywistości. Z resztą taki hurra optymizm może być katastrofalny w skutkach co pokazała ostatnia tragedia z batyskafem Titan.\nJa jestem jeszcze juniorem w szacowaniu tak rozległych prac na kursem i stąd od początku używam narzędzia ( Toggl Track) do śledzenia każdej minuty poświęconej na prace. Dzięki temu wiem dokładnie ile zajmuje każdy aspekt prac, a dzięki temu przestanę być juniorem, bo będę miał doświadczenie poparte dokładnymi danymi. Brawo dla mnie 😅\nSzacowanie dla aplikacji i systemów W przypadku aplikacji jest trochę łatwiej. Tam projektujemy nieprzewidywalność w postaci wielu stopni redundancji ( Design for failure). Jeśli robimy to dobrze i testujemy wywołując te awarie sztucznie przed ich prawdziwym wystąpieniem to możemy być całkiem nieźle przygotowani.\nCo do planów dotyczących wydajności to mamy wspaniałe narzędzia do ogarniania tego. To wszelkiego rodzaju mechanizmy autoskalowania. I nie dotyczy to tylko kontenerów i Kubernetesa. U dostawców chmury bez problemu wyskalujemy się czy to na serverless czy na tradycyjnych maszynach wirtualnych.\nNasze systemy też się uczą poprzez gromadzenie danych z metryk. To również sprzyja lepszemu szacowaniu i przygotowaniu na zwiększone użycie usług. Połączenie danych i skalowania daje nam proaktywne podejście, które jest efektywniejsze i tańsze.\nBo wiadomo - z komputerami jest łatwiej. To my z reguły jesteśmy tym trudniejszym kawałkiem układanki.\n","tags":["autoskalowanie","devops","edukacja","kurs","rozwój-osobisty"],"title":"Newsletter #77 - Dlaczego jesteśmy kiepscy w szacowaniu"},{"categories":["newsletter"],"date":"June 14, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/76/","section":"newsletter-archive","summary":"Dzisiaj druga i ostatnia piątka polecanych lektur na wakacje.\n6 - Factfullness\nWciąż myślisz, że Afryka jest biedna? Czy wiesz ile ludzi na świecie żyje w ubóstwie?\nTa pozycja pokazuje jak bardzo nieaktualna może być nasza wiedza. Mi otworzyła oczy na postęp, który w ostatnich dziesięcioleciach zmienił stereotypy, które mogłeś jeszcze wyciągnąć ze szkoły lub z innych źródeł.\nPolecam przeczytać, aby zacząć myśleć o tym jak szybko dezaktualizuje się nie tylko technologia, ale jak stereotypy o postępie zderzane są z rzeczywistością opartą o fakty. Warto zapamiętać, że w wiadomościach będą głównie kataklizmy, a o kroczący postęp będzie po prostu pomijany.\nJa dzięki temu ćwiczę wdzięczność, bo widzę jaki postęp w ostatnich latach widać na ulicach mojego miasta i nie tylko.\n7 - Quiet (IMHO polski tytuł jest dziwny…)\nIntrowertycy górą! Tak bym podsumował tą książkę i jeśli też czujesz, że lepiej czujesz się z komputerami (lub w małym towarzystwie) to polecam Ci tą książkę. Może tak jak mi uświadomi Ci, że moda na ekstrawertyzm jest bzdurą i dzisiejszy świat technologii zbudowali i wciąż budują introwertycy.\n8 - How to be imperfectionist\nNie zaczynasz rzeczy, bo obawiasz się, że będą nieidealne? Chcesz cały czas coś poprawiać zamiast powiedzieć, że może jest “wystarczająco dobre”?\nJa wciąż uważam się za perfekcjonistę, ale między innymi ta krótka pozycja pozwoliła mi wejść na ścieżkę wychodzenia z tego podejścia.\n9 - Zasady\nUwielbiam tą książkę. Być może dlatego, że lubię zasady, a te przedstawione przez autora podsumowują trudne czasem prawdy o tym jak żyć lepiej i odnieść sukces. Nie jest to napisane przez pseudo-coacha, który zarabia na swoich złotych radach i publikacjach, a przez osobę, która osiągnęła już w swoim życiu sporo i dzieli się swoimi przemyśleniami.\nNapisał ją Ray Dalio - założyciel olbrzymiego funduszu hedgingowego Bridgewater. Ray opisuje zadady, które sprawdzał na sobie i swojej firmie przez kilkadziesiąt lat.\nJa stamtąd pamiętam między innymi zasadę szczerości, którą wprowadzał w firmie Ray. Okazuje się, że średnio zajmuje 18 miesięcy, aby przyzwyczaić się do mówienie prosto z mostu i też odbierania szczerego feedbacku.\n10 - Status\nCałkiem możliwe, że ta pozycja pomoże Ci podobnie jak mi zrozumieć przynajmniej połowę ludzkich zachowań. My wciąż podświadomie walczymy o status i jeśli chcesz się dowiedzieć w jaki sposób możesz to wykorzystać to śmiało sięgnij po tę pozycję.\nAutorem jest Artur Król, którego znam osobiście i książka zawiera mnóstwo konkretów, które autor zbierał przez kilka ostatnich lat.\nA jak już zrozumiesz o co chodzi ze statusem to inaczej spojrzysz na zachowania swoje i innych - przekonaj się sam.\n","tags":["biznes","devops","edukacja","książki","rozwój-osobisty"],"title":"Newsletter #76  - Wakacyjne lektury dla ciekawskich"},{"categories":["newsletter"],"date":"June 6, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/75/","section":"newsletter-archive","summary":"Wkrótce wakacje i możliwe, że będziesz miał więcej wolnego czasu dla siebie. Jeśli chciałbyś jego część poświęcić na poznanie czegoś ciekawego poza to przygotowałem dla Ciebie listę ciekawych pozycji do przeczytania.\nSwego czasu nagrałem już wideo o książkach, bo wierzę, że tak możemy zmienić swoje myślenie. Jeśli chcesz być lepszy w DevOps jako współtworzeniu kultury organizacji czy być postrzegany jako ekspert to zachęcamy Cię do przeczytania (lub przesłuchania w formie audiobooka) pozycji, które wybrałem.\nTo jest moja subiektywna lista, którą wybrałem na podstawie przeczytania kilkuset pozycji i właśnie te uważam za najbardziej wartościowe.\nDzisiaj część pierwsza 5 książek, a za tydzień kolejna.\n1 - Porozumienie bez przemocy (Nonviolent communication a.k.a. NVC)\nMoże Cię zmylić tytuł, bo to nie chodzi o to jak mówić łagodnie i unikać przemocy. Ta książka jest moim zdaniem obowiązkowa, aby utrwalić sobie w głowie myślenie o potrzebach swoich i innych ludzi. To stoi za dużą częścią naszych podświadomych działań i wielu nieporozumień w pracy oraz poza nią.\n2 - Pięć dysfunkcji pracy zespołu\nZapewne pracujesz w zespole lub przynajmniej współpracujesz z innymi. Ta książka jest pisana w formie opowieści (tak jak Projekt Feniks, którego tutaj pomijam) i czyta/słucha się przyjemnie.\nDla mnie ciekawą rzeczą było odkrycie, że unikanie konfliktów jest niekorzystne. Jeśli coś jest ważne to czasem nie da się uniknąć gorącej dyskusji. Myślenie, że dobre zespoły zawsze się zgadzają we wszystkim jest obłudą. Jeśli dołożysz wiedzę o NVC to wszystko zaczyna mieć sens.\n3 - Gdy regułą jest brak reguł. Netflix i filozofia przemiany (“No rules rules” - zdecydowanie wolę angielski tytuł) _\n_ Ja zrezygnowałem z Netflixa jakiś czas temu, gdyż nie mogłem nic dla siebie tam znaleźć (mam specyficzny lub po prostu jestem wybredny).\nNie oznacza to jednak, że nie podziwiam jak ta organizacja zrewolucjonizowała rynek mediów, ale też była innowatorem od strony technologicznej. Chyba większość z nas słyszała o Chaos Monkey, ale jest też wiele innych “małp” wchodzących w skład wymyślonych na potrzeby skalowania całej armii.\nTa książka opisuje stronę organizacyjną i wciąż wiele organizacji stara się naśladować ich podejście, bo jak widać to zadziałało i przyniosło im rewelacyjne rezultaty. _\n_\n4 - DRIVE\nDuża część ludzi wciąż myśli, że to pieniądze są największym motywatorem. My w IT żyjemy trochę w bańce i niektórzy doświadczyli już tego na własnej skórze, że w pewnym momencie liczy się coś więcej. Okazuje się, że nasza motywacja leży głębiej, a z tej książki dowiesz się z czego się dokładnie składa.\nTo nie są wymysły autora, a poparte badaniami opisy tego co jest obserwowane w świecie od dawna. Inaczej nie doszlibyśmy tak daleko jako cywilizacja, gdyby każdy był motywowany tylko marchewką w postaci comiesięcznej pensji.\n5 - Głaskologia\nTo polska książka i sam uwielbiam Miłosza Brzezińskiego - zdecydowanie polecam w tym wypadku formę audiobooka, bo to jak ona jest czytana przez autora dodaje drugie tyle do wartości tej pozycji!\nStąd również dowiesz się na podstawie przytoczonych badań jak działamy jako ludzie i co możesz zrobić, aby zrozumieć działanie swoje i innych. A do tego jest napisana (i czytana!) z dużą dawką humoru.\nPolecam dla miłośników “czekolady”! (Ci co przeczytają będą wiedzieć)\n","tags":["biznes","devops","edukacja","książki","rozwój-osobisty"],"title":"Newsletter #75 - Czym karmić umysł w wakacje"},{"categories":["newsletter"],"date":"May 30, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/74/","section":"newsletter-archive","summary":"W tamtym tygodniu wypuściłem pierwszą część mojego kursu. To nie koniec, bo wciąż tworzę drugą jego część PRO z zaawansowaną treścią.\nTeraz zastanawiam się, że może jednak to było po prostu głupie. Mówię o tworzeniu dwóch kursów na raz i to z niezbyt trywialnego tematu (szczególnie część PRO).\nDzisiaj podzielę się moimi wątpliwościami, bo może Ty też czasem rozmyślasz nad swoimi decyzjami co do swojej kariery.\nDlaczego wybrałem skupienie Pewnie zauważyłeś, że poza tym newsletterem nie wypuszczam innych materiałów. To konsekwencja mojego wyboru. Skupiam prawie cały mój czas na przygotowywaniu kursu, sprawdzaniu dokumentacji, przygotowaniu wideo i treściwych labów.\nPostanowiłem śledzić na co dokładnie poświęcam swój czas i to mi pozwoliło zauważyć jak go niewiele mam! Tym bardziej postanowiłem odrzucać większość propozycji poprowadzenia szkoleń do czasu wypuszczenia całości materiałów. Do tego nie kręcę wideo, nie chodzę na konferencje (poza KubeCon), bo to są cenne godziny lub raczej dni.\nNie jest jednak tak różowo jak bym przypuszczał, że będzie.\nNegatywne konsekwencje Z takim pełnym skupieniem przychodzą nieprzewidziane przeze mnie wcześniej konsekwencje. Jak już pisałem nie wpuszczam innych materiałów i przez to można odnieść wrażenie, że… nic nie robię! Zaszyłem się gdzieś i pewnie przejadam kasę z przedsprzedaży!\nWidzę to głównie po liczbie subskrybentów. Gdy wypuszczałem treści na YouTube, prowadziłem webinary, warsztaty to widziałem przyrost i zainteresowanie czy to newsletterem czy moimi kontami na social media.\nA tak rośnie moja frustracja, bo cały materiał jeszcze nie jest gotowy, a w mojej głowie pojawiają się wątpliwości.\nA co jeśli to błąd? Chyba nikt nie lubi błądzić. Ja również. Chciałbym, aby wszystko szło gładko wedle sprawdzonego planu i na samym końcu triumfalny sukces, autografy, wywiady i wieczna sława!\nTo są bzdury i mrzonki niestety. Są one dodatkowo podsycane przez wszechobecne social media z ludźmi odnoszącymi olbrzymie wręcz sukcesy i to niemalże bez wysiłku. Życie tak nie wygląda. Ja się już z tym pogodziłem i jest mi łatwiej.\nA czym jest błąd? Jeśli przyjmiesz podejście ciągłego uczenia się to będzie to tylko okazja do korekty kursu. Gorzej jeśli będziesz to przeżywał podsycony wewnętrznym perfekcjonizmem. Ja wybrałem drogę uczenia się. Niemniej w gorszych momentach przeglądam oferty pracy - tak na wszelki jak mój eksperyment nie wypali…\nPewne jest jedno To, że zawsze będzie towarzyszyć mi niepewność. Zaakceptowanie tego ułatwia mi podejmowania ryzyka i prowadzenia kolejnych mniejszych lub większych eksperymentów.\nW międzyczasie przede mną jeszcze uczenie się większej cierpliwości, wytrwałości i delegowania rzeczy do ekspertów.\nCzy jest łatwo? Nie, ale coraz łatwiej. Może i wiedza z obszaru DevOps jest ciekawa, ale na dłuższą metę to czego się uczę teraz będzie procentować o wiele dłużej. Po prostu - sama technologia nie wystarczy.\nP.S. Jeśli jesteś ciekawy kontynuacji mojej przygody z awarią Macbooka to spieszę donieść, że po wizycie w serwisie najwidoczniej się przestraszył i zaczął się już ładować. Najwidoczniej strzelił tylko focha. Mam nadzieję, że będzie się zachowywał poprawnie - przynajmniej do publikacji kursu!\n","tags":["biznes","edukacja","kubernetes","rozwój-osobisty"],"title":"Newsletter #74 - Możliwe, że to było głupie"},{"categories":["newsletter"],"date":"May 23, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/73/","section":"newsletter-archive","summary":"Nic nie zapowiadało, że tak się skończy ten wyjazd. Wyrwałem się na chwilę sprzed komputera odwiedzić naszych południowych sąsiadów (ci od dobrego makaronu i innych przysmaków) i nabrać energii do intensywnej pracy nad kursem, a tu taki zonk. Tuż przed powrotem przestała mi się ładować bateria w moim Macbooku. Początkowo obwiniałem zepsuty kabel lub zasilacz. Do tego zamiast wrócić normalnie i mieć więcej czasu na napisanie dla Ciebie newslettera to znacząco opóźnił się mój lot powrotny przez co mam na to mniej czasu. Z takiego zrządzenia losu przygotowałem tym razem moje przemyślenia wynikające z (tymczasowej?) przesiadki z Macbooka na laptopa z Ubuntu.\nPiszę ten newsletter dzięki chmurze Chodzi mi o usługi chmurowe na desktopa takie jak Google Drive, iCloud czy synchronizacja ustawień Google Chrome (jak dobrze, że nie używam Safari). Dzięki nim w kilka minut mam dostęp do wszystkich moich zasobów, mogę się dostać do moich serwisów. I to jest naprawdę super. Jak dla mnie to jest przykład użytecznej technologii, która rozwiązuje nasze realne, codzienne problemy (o ile codziennie zdarzają Ci się podobne awarie).\nWow - Ubuntu na desktop jest bardzo szybkie Jestem pod wrażeniem - działa to baaardzo szybko, animacje okien płynne i uruchamianie aplikacji również. Nie bez znaczenia jest też fakt, że używam laptopa dość potężnego (AMD Ryzen 7 z 8 rdzeni, 32GB RAM, 1TB SSD), którego zakupiłem na potrzeby kursu - używam go do testów labów do modułów ze stawianiem złożonego klastra Kubernetes na on-prem. O tym dlaczego tak zrobiłem napiszę lub nagram wideo kiedy indziej (bo przecież mogłem użyć chmury). Tak czy siak - jest moc i pozytywne wrażenia!\n\u0026hellip;ale wciąż są problemy jakie pamiętam Żeby nie było tak słodko to uważam, że ten rok nie jest rokiem dominacji Linuksa (czy też bardziej Ubuntu) na desktopie. Do poprawnego działania wifi musiałem znowu googlować, a później eksperymentować z parametrami modułu kernela do obsługi karty sieciowej. Takie zabawy pozwoliły mi zdobyć kiedyś sporo wiedzy, ale teraz wolę jednak, aby takie podstawowe rzeczy działały od ręki.\nDo dobrego się szybko przyzwyczaja Do czasu awarii to poza wybitnie beznadzieją klawiaturą (mam przez to zewnętrzną, z której piszę też na Ubuntu) Macbook sprawował się naprawdę bardzo dobrze. Dopiero teraz ta przesiadka uzmysłowiła mi jak szybko się przyzwyczaiłem do jego bezobsługowości. Zmiana nie przychodzi nam łatwo i szczególnie taka, która dokłada Ci pracy, a tak właśnie czuję się na Ubuntu niestety.\n…ale za to trzeba słono płacić Nie jestem żadnym fanatykiem Apple, ale nie bez przyczyny jest to firma o kapitalizacji 2.7 miliarda dolarów. To po prostu działa i w dużej mierze przez to, że inni muszą się dostosować do reguł przez nich narzuconych, a przez to każdy niemal soft działa na Macach bez problemu. Pisząc to leci sobie muzyka z wbudowanych głośników laptopa z Ubuntu ze znaczkiem B\u0026amp;O (Bang \u0026amp; Olufsen), ale jakoś nie dorasta do pięt tym wbudowanym w Macu. To są takie małe rzeczy, które spinają się w spójną całość i pozytywne wrażenia. Ja jednak póki co postanowiłem płacić, ponieważ liczę teraz każdą godzinę, którą mogę poświęcić na pisanie, nagrywanie czy tworzenie innych treści (obecnie kursu). Dla mnie czas ma teraz olbrzymie znaczenie i dlatego wybieram rozwiązania, dzięki którym go trochę odzyskuję.\nMoże mają rację zwolennicy teorii spiskowych? No bo jak po 4 latach bateria może przestać się ładować?? To jest absurd! Czy to faktycznie zabieg postarzający sztucznie sprzęt zmuszający do wizyty w serwisie? No bo sam nie wymienię (bateria “wbudowana”), a naprawa stanowi około 30% wartości tego potwora do testów z Ubuntu! Może być to też przypadek i zwyczajny pech…\nPrzezorny zawsze przygotowany Kończę ten wywód z nadzieją, że wszystko skończy się dobrze. Ten newsletter to tylko przypomnienie, że wszystko się z czasem zepsuje i to tylko drobna przeszkoda jakich wiele przed nami. Ja na szczęście w tym wypadku zadziałało u mnie rozwiązanie zapasowe, a w razie czego mam jeszcze backupy, które tworzę w kilku miejscach (Time Machine jest pod tym względem genialny). Bo wiadomo - liczy się, aby #ZawszeDoPrzodu.\n","tags":["apple","macbook","sre"],"title":"Newsletter #73 - Apple robi mi chyba na złość"},{"categories":["newsletter"],"date":"May 16, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/72/","section":"newsletter-archive","summary":"Dzisiaj druga część wybranych przeze mnie prezentacji z KubeCon EU 2023 z Amsterdamu.\nZatem nie przedłużając zapraszam do przejrzenia moich wyborów i również obejrzenia.\n6 - Wyzwania dotyczące skalowania **\n** Nasz człowiek w Google - Wojtek Tyczyński - opowiedział w tej prezentacji o wyzwaniach dotyczących skalowania klastrów.\nNie byłem świadomy jak bardzo złożony jest to temat i jak wiele aspektów wpływa na wydajność Kubernetesa - włącznie z wersjami Go.\nMiałem przyjemność widzieć prezentację na żywo i pod koniec zadałem Wojtkowi pytanie co wpływa najbardziej na wydajność klastrów.\nJego odpowiedź to (ten fragment pozostanie jedynie w wersji mailowej newslettera).\n7 - Treściwie i konkretnie o projektowaniu niezawodności **\n** Bardzo podobała mi się ta sesja - dużo konkretów i to świetnie opowiedzianych! Przedstawiona przez ludzi z Google opowiada o tym jak projektować systemy (również te oparte o Kubernetes), aby były niezawodne.\nPolecam obejrzeć fragment o odwróconej piramidzie, bo dla mnie to inne pokazanie koncepcji “Design for Failure”. Nie przegap też zabawnego fragmentu o multiverse :)\nZobacz koniecznie to wideo jeśli lubisz lub pracujesz zgodnie z podejściem Site Reliability Engineering, bo panowie pokazują tu dokładnie liczby i co wpływa na dodawanie kolejnych dziewiątek do SLA.\n8 - O zarządzaniu zasobami - zaawansowane\nZ tej sesji dowiedziałem się po co tyle pary poszło w adopcję cgroups v2. Otóż (miejmy nadzieję) wkrótce będziemy mogli zarządzać lepiej zasobami takimi jak przepustowość sieci i liczbie operacji IO na dyskach. Bo nie wiem czy wiesz, ale to obecnie wyróżna kontenery od VMek - te pierwsze współdzielą kernel, a tym samym struktury kernela takie jak pagecache i fizyczne urządzenia typu karty sieciowe czy dyski.\nTa sesja to ciekawa dyskusja ekspertów w tej dziedzinie i polecam objerzeć, aby dowiedzieć się co nas czeka w przyszłości. Ja się dowiedziałem, że obok CSI, CRI, CNI czeka nas kolejny interfejs - NRI od Node Resource Interface pomocny przy zarządzaniu zasobami klastra.\nNo i z tej rozmowy wyniosłem też, że tzw. Topology Aware Scheduling jest gorącym tematem - to dobrze, że jest on częścią modułów PRO mojego kursu :)\n9 - Ciekawa lekcje o ustawieniu limitów\nTo nie pierwszy raz, gdy wychodzi problem z niedostatecznie szybkim działaniem kontenerów na Kubernetes. Z tej sesji w szczegółach dowiesz się co jest przyczyną i jak sobie z tym radzić.\nJeśli czas Cię goni i chcesz tylko konkretne rozwiązanie to oto ono: (ten fragment pozostanie jedynie w wersji mailowej newslettera)\n10 - A jednak Service Mesh z sidecare’ami ma wciąż sens\nCo prawda tą prezentację prowadził pan z Linkerd to jednak w dość jasny i przekonywujący sposób pokazał dlaczego przyszłość Service Mesh będzie powiązana z dodatkowymi kontenerami proxy dopinanymi do aplikacji.\nWarto obejrzeć kilka przedstawionych scenariuszy, gdzie obalonych jest kilka mitów dotyczących nadmiernego wykorzystania zasobów czy wprowadzonego opóźnieni przez takie kontenery.\n","tags":["argocd","biznes","buildpacks","federacja","gitops","hacking","kubecon","kubefed","kubernetes","liqo"],"title":"Newsletter #72 - Top 10 prezentacji z KubeCon EU 2023 - część 2"},{"categories":["newsletter"],"date":"May 9, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/71/","section":"newsletter-archive","summary":"W końcu jest. Na kanale YouTube CNCF opublikowane zostały nagrania z tegorocznego KubeCon EU 2023. Możesz samodzielnie je przejrzeć (jest ich prawie 300), ale nie musisz, bo ja zrobiłem to za Ciebie i wybrałem 10 najciekawszych nagrań.\nByło sporo nudnych lub ciężkich w odbiorze, ale mi udało się dotrzeć do perełek. Na niektórych nawet byłem (na nudnych też, ale te pominąłem) siedząc w pierwszym rzędzie - w końcu to jak koncert tylko, że taka wersja dla geeków ;)\nDzisiaj przedstawiam pierwszą część, a za tydzień będzie druga.\n10 najciekawszych prezentacji - pierwsza piątka 1 - Hackowanie klastra Kubernetes\nNasza rodaczka zapełniła chyba największą salę na konferencji i pokazała jak łatwo można zhackować nieodpowiednio zabezpieczony klaster.\nPolecam w szczególności tym, którzy mają klastry on-prem. Ja sam się dowiedziałem o istnieniu prezentowanego tam narzędzia kubeletctl.\n2 - O buildpackach opowiedziane w ciekawy sposób\nTo moja ulubiona sesja. Byłem na niej osobiście i podziwiam jak w 35 minutach można ciekawie opowiedzieć o technologii z humorem i dużą dawką informacji od podstaw do zaawansowanych ficzerów.\nLubię koncept unifikacji budowy obrazów jak np. Source-to-Image, gdyż pomógł moim klientom wdrożyć szybko kontenery na OpenShift. Buildpacki są ewolucją tego dostosowaną dla Kubernetesa i jeśli męczy Cię utrzymywanie definicji w Dockerfile to obejrzyj to koniecznie.\n3 - Federacja klastrów w poruszających się pojazdach w armii holenderskiej\nKolejna sesja, na której byłem osobiście i to ze szczególnego powodu - współprowadziła ją moja dobra koleżanka ze studiów, która mieszka w Holandii i uczestniczyła w tym ciekawym projekcie.\nWykorzystanie wielu klastrów uruchomionych na pojazdach wojskowych łączących się ze sobą nawzajem i z bazą nie jest trywialnym zagadnieniem. Bardzo mi się podoba ja to zostało rozwiązane i sam zainteresuję się projektem Liqo, który był tam wykorzystany.\n4 - Wyzwania GitOps w praktyce w Adobe\nLubisz GitOps? To koniecznie obejrzyj tą prezentację. Jedna z ciekawszych jakie znalazłem i dostarcza wielu wskazówek do wdrożeń podejścia GitOps na większą skalę.\nOpiera się o Argo CD, ale myślę, że koncepty są uniwersalne również dla Flux CD. Fajnie omówione jest tam podejście do testowania wdrożeń korzystając z Jobów, synchronizacji wdrożeń wielu mikroserwisów, ale mi najbardziej podobał się omawiany pod koniec problem synchronizacji zmian w infrastrukturze i aplikacjach.\n5 - Co jest najważniejsze w budowaniu biznesu z technologiami Cloud Native\nTym razem to panel dyskusyjny z udziałem gwiazd sceny Cloud Native takich jak Liz Rice i Kelsey Hightower (koniecznie zobacz jak się przedstawia i jaka jest reakcja sali :)\nByłem na tej sesji osobiście choć nie usiadłem w pierwszym rzędzie jak zazwyczaj (było to jednak 2 lub 3), bo sala była pełna.\nDlaczego warto ją obejrzeć? Jeśli jesteś doświadczony to nie będzie dla Ciebie zaskoczeniem, że Ci eksperci niewiele mówią o technologii, ponieważ… to nie to jest najważniejszy jeśli chce się osiągnąć sukces w tej (i pewnie nie tylko tej) branży.\nZ tego samego powodu w moim TOP 10 umiejętności DevOps na końcu omawiam te eksperckie, które nie są związane z technologią, a są według mnie o wiele bardziej krytyczne.\nZa tydzień wyślę drugą część z kolejnymi, bardzo ciekawymi prezentacjami i wskazówkami, które z nich wyniosłem.\n","tags":["argocd","biznes","buildpacks","federacja","gitops","hacking","kubecon","kubefed","kubernetes","liqo"],"title":"Newsletter #71 - Top 10 prezentacji z KubeCon EU 2023 - część 1"},{"categories":["newsletter"],"date":"April 25, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/70/","section":"newsletter-archive","summary":"Co to była za konferencja! Mówię oczywiście o zeszłotygodniowym KubeCon EU 2023 w Amsterdamie, z którego niedawno wróciłem.\nZa wcześnie jeszcze na podsumowanie - to zrobię już niedługo jak tylko pojawią się nagrania z najciekawszych prezentacji. A mam sporo przemyśleń, wskazówek i ciekawych narzędzi.\nW międzyczasie zapraszam do obejrzenia kilku krótkich filmów i LIVE z ostatniego dnia - są one dostępne na tej playliście.\nNowy odcinek podcastu z Michałem Furmankiewiczem o Azure Z drobnym opóźnieniem, ale już jest - nowy odcinek podcastu, gdzie z Michałem Furmankiewiczem rozmawiamy o popularności Azure i tym co jest pod spodem.\nSporo się dowiedziałem i nie mogę się doczekać premiery polskiego regionu chmury Azure w Polsce!\nJednocześnie przepraszam wszystkich, którzy słuchają mojego podcastu - chciałbym nagruweać systematycznie i częściej, ale nie wyrabiam na zakrętach :( Obiecuję poprawę, bo dostaję sygnały, że podcast się “słucha”.\nPodcast do przesłuchania na stronie odcinka jak również na Twojej ulubionej platformie do podcastów.\nCiekawe nowości od Azure Zostając przy Azure znalazłem trzy ciekawe nowości, które ostatnio zostały opublikowane.\n1 - Dla leniwych i wygodnych - AKS LTS daje 2 lata spokoju!\nOsobiście lubię GKE z wygodnym zarządzaniem kanałami aktualizacji, a tu Azure poszedł jeszcze łatwiejszą ścieżką. Od wersji 1.27 będziesz mógł przez dwa lata nie martwić się o aktualizacje i zostać z wersją LTS przez 2 lata. Kuszące i rozleniwiające.\n2 - Trzymaj koszty w ryzach\nOd teraz dzięki integracji projektu OpenCost z AKS jest możliwe śledzenie kosztów projektów na baaardzo granularnym poziomie.\nDo kosztów infrastruktury i usług Azure możesz dorzucić szczegóły Twoich aplikacji działających w Kubernetesie. Zatem teraz każdy MHz procesora, bajty przesyłane przez sieć i MB pożerane przez kontenery mogą być śledzone i przypisywane projektom.\nW dobie cięcia kosztów to jest naprawdę przydatne\n**3 - Zarządzaj zasobami Azure przez Kubernetes\n** To taki odpowiednik “sendmailem przez emacsa” (suchar ze starych lat), ale jeśli lubisz yamle, GitOps i Kubernetes to możesz zarządzać ponad 100 usług na Azure korzystając z niedawno wydanej wersji 2.0 dedykowanego operatora Azure dla Kubernetes.\nLepszy top dla Kubernetes Jeśli “kubectl top” wydaje Ci się toporny i brakuje Ci szczegółów to polecam narzędzie ktop. Tam znajdziesz wszystko co pozwoli Ci określić na szybko stan Twojego klastra i kontenerów na nim uruchomionych.\n","tags":["aks","azure","ktop","kubecon","kubernetes","opencost","operator","podcast"],"title":"Newsletter #70 - Jak Azure AKS nas rozleniwia"},{"categories":null,"date":"April 24, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/18/","section":"podcast","summary":"Dlaczego chmura Azure jest tak popularna w Polsce? Zapytałem o to naszego człowieka w Azure, czyli Michała Furmankiewicza.\nMichał zna się na chmurze Azure jak chyba nikt inny w Polsce i jednocześnie obecnie w Microsoft współtworzy ją będąc liderem globalnego zespołu architektów. To również współtwórca sukcesu Chmurowiska, tytan pracy i doświadczony architekt rozwiązań chmurowych.\nUsiedliśmy i porozmawialiśmy o ciekawych tematach takich jak:\n🔷 Jak wygląda sprawa z regionem Azure w Polsce? I czy będzie w nim AKS? 😅\n🔷 Jak Microsoft tworzy nowe regiony? Ile to zajmuje i czy w dobie drogiej energii stosuje jakieś sztuczki, aby zapewnić odpowiednią moc w przystępnej cenie?\n🔷 Czy to prawda, że pod spodem Azure składa się głównie z systemów linuksowych?\n🔷 Co jest największą przeszkodą w adopcji chmury w ogóle?\n🔷 Banki i chmura - kilka lat temu to było niemożliwe, a jak to wygląda obecnie?\n","tags":["azure","cloud"],"title":"18 - Dlaczego chmura Azure jest tak popularna w Polsce? Rozmowa z Michałem Furmankiewiczem"},{"categories":["newsletter"],"date":"April 18, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/69/","section":"newsletter-archive","summary":"Jak to czytasz to ja zapewne jestem w drodze, albo już w Amsterdamie na największej konferencji poświęconej Kubernetes i Cloud Native w Europie - KubeCon EU 2023.\nBędę tam, aby dowiedzieć się co nas czeka w najbliższym czasie, a relacje o tym postaram się zdawać na bieżąco oraz na piątkowym LIVE prosto z konferencji (szczegóły poniżej).\nJeśli będziesz na miejscu to zapraszam na dedykowany polski kanał Slack, gdzie dzielimy się tym co najlepsze na konferencji - #kubecon-eu-2023-pl\nJuż jest - Kubernetes 1.27 W nowej wersji nie ma rewolucji. I dobrze. Nie trzeba się spinać i można spokojnie aktualizować.\nPo wszystkie szczegóły odsyłam jak zwykle do podsumowania od Sysdig, a ja wybrałem trzy najważniejsze według mnie zmiany.\nJeśli masz klaster on-prem to popraw reguły sieciowe, bo trąbią o tym od dawna, że od tej wersji znikają obrazy z rejestru k8s.gcr.io i będą dostępne bardziej uniwersalnie z rejestru registry.k8s.io. To rodzaj optymalizacji sieciowej, ale też odciążenie Google, który przez długi czas sponsorował projekt i w tym hostował wszystkie oficjalne obrazy kontenerów z komponentami Kubernetes.\nTo jest baaardzo ciekawy ficzer. Mowa o dynamicznej alokacji zasobów. Co prawda wchodzi dopiero do alpha, ale według mnie to super rozwiązanie. Zadowolenie powinni być ci, którzy uruchamiają sporo kontenerów z Javą.\nTa zmiana wprowadza możliwość dynamicznej zmiany przydziału zasobów i dzięki temu na start kontener może dostać np. więcej CPU, a później bez restartu może być ta alokacja zmniejszona.\nMoże też dzięki temu wertykalny autoskaler będzie miał sens, bo obecnie osobiście nie znajduję większego zastosowania dla niego.\nCzy wprowadzenie reguł CEL zagrozi projektom typu OpenPolicyAgent i Kyverno? Być może i choć to również jest dopiero w fazie alpha to jednak filtrowanie zapytań bezpośrednio przez wbudowany kontroler, a nie z użyciem webhooka, rodzi o wiele mniej problemów wydajnościowych.\nTrzymam kciuki za ten ficzer, bo czyni z Kubernetes jeszcze potężniejszą platformę i łata niedoskonałości RBAC.\nPodman Desktop jako alternatywa dla Docker Desktop? Po tym jak 6-krotnie przyspieszyli Podmana (alternatywa dla Docker) ich pokrewny projekt Podman Desktop ogłosił w nowej wersji wsparcie dla tworzenia klastrów Kubernetes używając Kind.\nTo wydaje się być alternatywa dla tych, którzy nie chcą wpaść w pułapkę licencjonowania produktu Docker Desktop.\nWygląda to całkiem ok i trzymam kciuki za ten projekt. Sprawdź sam - mają wersję dla Windows, Mac i Linux (jeśli lubisz GUI).\nLIVE z Amsterdamu - podsumowanie KubeCon EU 2023 O ile nie zabraknie internetów na konferencji (ma być 10 tysięcy uczestników) to w ten piątek o 10:00 odbędzie się LIVE prosto z konferencji.\nPodsumuję w nim najważniejsze rzeczy i postaram się zaprosić gości. Trzymam kciuki, aby się udało, a Ciebie zapraszam do obejrzenia i zadawania pytań.\nLink do YouTube\n","tags":["docker","kubecon","kubernetes","kyverno","opa","podman"],"title":"Newsletter #69 - Co przynosi nowy Kubernetes 1.27"},{"categories":["newsletter"],"date":"April 4, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/68/","section":"newsletter-archive","summary":"Tym razem garść nowości i ciekawostek o Kubernetesie. Muszę przyznać, że coraz trudniej jest mi znaleźć coś ciekawego.\nMoże to po prostu oznacza, że większość jest już ogarnięta, a pozostaje nam jedynie doglądanie i udoskonalanie naszych “samograjów” kontenerowych na klastrach?\nEwentualnie to cisza przed burzą, bo wkrótce i tak wszystkim będzie zarządzać AI typu ChatGPT, a nam przyjdzie zajmować się wypiekami serników lub sprzedażą kebabów ;)\nOznaczanie autorów zmian w GitOps z Kyverno Fajny GitOps jest i nie ma co do tego wątpliwości. Może być jeszcze fajniejszy jeśli z poziomu metadanych każdego obiektu możesz się dowiedzieć o autorze ostatniej zmiany lub innych informacji z git.\nJak to zrobić za pomocą Kyverno jest opisane w tym wpisie. To kolejny punkt ewolucji podejścia GitOps i dość łatwy do zaaplikowania.\nMam nadzieję tylko, że nie posłuży to do wskazywania kozła ofiarnego zmian, które mogły doprowadzić do awarii. W końcu kultura “blameless post-mortem” powinna już u nas zagościć na stałe.\nTestuj Kubernetes bez węzłów z Kwok Jeśli chcesz potestować bardziej samo API Kubernetesa lub tylko jego komponenty z Control Plane (np. scheduler) to może Cię zainteresować projekt Kwok.\nDzięki niemu odpalisz okrojonego Kubernetesa z nawet tysiącem nieistniejących węzłów i puścisz wodze fantazji. To nawet lepsze niż istniejący już wcześniej symulator planisty (czyli schedulera). Do testów w ramach potoków CI/CD jak znalazł!\nZarządzanie kosztami ma sens, ale… większość tego nie robi Jeden z powodów dlaczego firmy używają Kubernesa to koszty. Te są szczególnie ważne ostatnio, gdy słyszymy o zwolnieniach mających poprawić sytuację finansową wielu organizacji.\nI pomimo tego, że nie jest to super złożone (między innymi dzięki OpenCost) to według Sysdig bardzo niewiele organizacji się na to decyduje.\nZarządzanie rezerwacjami, limitami, priorytetami, autoskalowanie podów i klastra - to wszystko jest na wyciągnięcie ręki. Nigdy nie było łatwiej oszczędzać na infrastrukturze i wyciskać na maksa z dostępnych zasobów.\nTo też powód, dla którego coraz więcej klastrów on-prem jest stawianych na bare-metal (bez vSphere), ale to już historia na oddzielny wątek.\nTwórz automatycznie mapy połączeń między podami Masz duży klaster? Nie łapiesz się co z czym gada? Może chcesz w końcu utworzyć reguły NetworkPolicy?\nJeśli tak to sprawdź ten projekt, który automatycznie utworzy Ci mapy połączeń między podami w Twoim klastrze.\nZapomnij o OPA lub Kyverno - nadchodzi CEL Kyverno jest fajne, OpenPolicyAgent w sumie też. Niemniej mają one jedną wadę - trzeba je instalować i utrzymywać.\nNa szczęście nadchodzi natywne rozwiązanie do filtrowania żądań przychodzących do klastra. To Common Expression Language, czyli w skrócie CEL. Co prawda jest jeszcze w fazie alpha, ale już teraz możesz sprawdzić jak to działa.\nDla mnie osobiście to jedna z najfajniejszych z dodatkowych funkcjonalności Kubernetes, która pozwala na zrobienie niemalże wszystkiego z Twoim klastrem. Dla dużych środowisk nie wyobrażam sobie działania bez tego.\nJeszcze lepsza integracja Vault z Kubernetes HashiCorp wypuścił niedawno dedykowany operator dla Vaulta. Wygląda przepięknie! Teraz integracja z Kubernetes i konfiguracja dostępu do danych z Vaulta jest bajecznie prosta. Do tego jest wsparcie dla rotowania danych dla natywnych obiektów (Deployment, DaemonSet, StatefulSet) i wsparcie dla metryk w formacie Prometheus.\nProponuję przynajmniej potestować, a później ruszyć pełną parą razem na przykład z dynamicznym dostępem do baz.\n","tags":["devsecops","gitops","kubernetes","kwok","kyverno","opa","opencost","security","sysdig","vault"],"title":"Newsletter #68 - Klaster Kubernetes bez węzłów"},{"categories":["newsletter"],"date":"March 28, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/67/","section":"newsletter-archive","summary":"Dzisiaj krótko. To wynik moich przemyśleń prac nad kursem. Tam zauważyłem jak trudno przekazać dużo treści z szacunkiem dla czasu odbiorcy.\nCzasem nie trzeba wiele pisać. Często o wiele bardziej liczą się konkrety. Dzisiaj wszystko jest szybkie i skierowane na atrakcyjną formę. Treść jest na drugim planie. Przy konwersacji często zapełniamy ciszę. W formie pisemnej rozpisujemy się, aby pokazać się z najlepszej strony. To ryzyko niespełnienia oczekiwań odbiorcy i odrzucenia nas lub naszej pracy. Niepotrzebnie.\nKrótkie formy są trudniejsze w tworzeniu i czasem trudniejsze w odbiorze. Ich tworzenie to walka z wewnętrzną potrzebą dopowiedzenia. Bardzo często nie potrzeba więcej.\n","tags":["devops"],"title":"Newsletter #67 - Krótko"},{"categories":["newsletter"],"date":"March 21, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/66/","section":"newsletter-archive","summary":"Amazon wydał niedawno nową wersję swojej dystrybucji linuksowej - Amazon Linux 2023. Kiedyś taka informacja byłaby szeroko komentowana, ale teraz przejdzie raczej bez echa. To dlatego, że nie ekscytujemy się już nowymi dystrybucjami, a ja postanowiłem poświęcić ten newsletter linuxowi – wspaniałemu kawałku oprogramowania, które zapoczątkowało moją karierę.\nCzy Linuks ma jeszcze znaczenie? Czasy świetności Linuksa może jeszcze nie przeminęły, ale nie odgrywa on tak dużej roli jak kiedyś. Teraz to tak zwane commodity, czyli chleb powszedni wszystkich pracujących w IT. Zakładamy już na początku, że każdy już go zna i wiemy jak go używać.\nNo bo spójrz, Kubernetes to tak naprawdę rozproszony Linuks z doskonałym REST API. To może być tajną przyczyną, dla której nie przejmujemy się co jest pod spodem. Te wszystkie wspaniałe ficzery, którymi ekscytowaliśmy się lata temu są bowiem ukryte w kontrolerach lub wykorzystywane w różnego rodzaju projektach.\nI dlatego też nie musisz znać Linuksa tak dogłębnie jak kiedyś. Jedynym obszarem, który pozostał związany z linuxem są kontenery. Budowa obrazów kontenerów wymaga wiedzy na temat funkcjonowania linuxa. Taki Dockerfile obecnie składa się głównie z dyrektyw RUN, w których często znajduje się wiele ciekawych komend zaczynając od instalacji pakietów aż po zaawansowane regexpy i inne magiczne triki.\nZatem owszem, Linuks ma nadal olbrzymie znaczenie, ale wiedza o nim jest ukryta i wykorzystujemy ją bardziej od strony użytkownika poprzez projekty typu Kubernetes.\nCzy dystrybucje mają jeszcze znaczenie? Kiedyś owszem, dystrybucje i różnice między nimi stanowiły źródło “ciekawych” dyskusji. Szczególnie miało to znaczenie przy obsłudze różnego rodzaju sprzętu, bowiem Linuks zarówno wtedy jak i teraz królował na serwerach.\nProducenci certyfikowali lub też wypuszczali sterowniki (moduły do kernela) na wybrane dystrybucje. I tak narodziła się hegemonia jednego systemu - Red Hat Enterprise Linux (RHEL).\nDla tych co nie chcieli płacić za wsparcie idealnym rozwiązaniem okazywał się CentOS. Do czasu aż Red Hat postanowił projekt popsućzmienić to i CentOS przestał być kompatybilny i być darmowym odpowiednikiem komercyjnego RHEL. Dla tych, którzy nadal płaczą za centosem jest na szczęście projekt RockyLinux.\nNatomiast to i tak nie ma większego znaczenia, szczególnie jeśli zagłębiasz się w świat Kubernetesa i kontenerów. Tam nie ma znaczenia dystrybucja - liczy się bowiem głównie kernel i środowisko uruchomieniowe dla kontenerów (np. containerd, CRI-O, Docker).\nW takim świecie dominuje Debian, który jest używany dla większości oficjalnych obrazów kontenerów. Na serwerach zaczyna dominować Ubuntu i widać to również na platformach chmurowych gdzie jest dostępna nawet wersja PRO.\nProjekty takie jak Alpine też mają swoje miejsce, ale jeśli czytałeś poprzedni newsletter to wiesz że może być to ryzykowne.\nDystrybucje mają mniejsze znaczenie ale sam Linuks ma się dobrze. Liczą się bardziej praktyczne umiejętności, które możesz wykorzystywać na co dzień.\nPoznawać dogłębnie czy dać sobie spokój? Dobra wiadomość jest taka, że nie musisz się już masterować ze wszystkich ficzerów kernela oraz tajników obsługi danej dystrybucji.\nJak już pisałem wcześniej ta wiedza jest wykorzystana w projektach takich jak Kubernetes, a dostawcy chmury publicznej również używają go pod spodem do oferowania ci usług za $.\nJeśli zaczynasz lub nie czujesz się pewnie z Linuksem to najlepiej zacznij używać go jako swoje podstawowe środowisko pracy. To zmusi cię do poznawania i używania komend na co dzień. Linuks raczejz pewnością nie wygra rywalizacji z windowsem jako środowisko desktopowe, ale jako natywny system do odpalania kontenerów (bez maszyn wirtualnych) nadaje się wyśmienicie. Do tego przyda ci się znajomość shella i najważniejszych komend.\nJeśli już w miarę ogarniasz Linuksa to nie musisz się męczyć z nim na desktopie. Dzięki WSL2 na windowsie lub natywnemu środowisku na macos możesz nadal używać ulubionych komend i cieszyć się z faktu, że każdy oprogramowanie będzie działać bez jakichś sztuczek jak to często ma miejsce na Linuksie.\nCo potrzebujesz znać z linuksa do swobodnej pracy? Zacząłbym od zarządzania procesami. W końcu kontenery to specjalne procesy linuksowe i warto abyś wiedział jak je obsługiwać.\nDo tego jeśli pracujesz lub chcesz pracować jako DevOps to element sieciowe są super istotne. Narzędzia takie jak iptables, zarządzanie interfejsami sieciowymi czyt tablicą routingu będą niezbędne do zarządzania plastrami Kubernetesa, które sam postawisz na przykład na on-prem.\nPotrzebujesz wiedzieć jak zarządzać pakietami dla linuksowych serwerów oraz definicji nowych obrazów kontenerów (i maszyn wirtualnych też - patrz Packer). Na szczęście nie musisz wiedzieć jak je tworzyć, bowiem ta wiedza nie jest już tak niezbędna odkąd mamy kontenery.\nNo i wspomniany wcześniej shell, czyli głównie Bash. Musisz wiedzieć jak swobodnie poruszać się po środowisku – czy to serwer czy też sesja na uruchomionym kontenerze. Z czasem odkryjesz też inne narzędzia typu sed, xargs, find, awk i praca z linii komend będzie czystą przyjemnością.\nAha – nie zapomnij również o VI. Może się okazać, że będzie to jedyny dostępny edytor, a ty będziesz potrzebować coś na szybko zmienić. I oczywiście naucz się z niego wychodzić, bo to może być na początku najważniejsza umiejętność 😅\n","tags":["centos","cloud","docker","kubernetes","linux","ubuntu"],"title":"Newsletter #66 - Czy Linuks ma jeszcze znaczenie?"},{"categories":["newsletter"],"date":"March 14, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/65/","section":"newsletter-archive","summary":"Wciąż moje główne zajęcie to tworzenie kursu, ale znajduję też czas na bycie na bieżąco z nowościami i ciekawymi projektami. Dzisiaj porcja tego co zwróciło moją uwagę ostatnio z moimi komentarzami.\nLżejsze Istio Ambient nadchodzi Minęło już kilka miesięcy odkąd omawiałem na jednym z wydarzeń LIVE ciekawą, nową funkcję Istio Ambient. Pozwala ona zredukować zużycie zasobów i zdecydowanie uprościć deployment Istio. Jest to szczególnie przydatne w dużych środowiskach gdzie dokładanie do każdego poda dedykowanego kontenera z Envoy proxy może znacząco podnieść wykorzystanie zasobów klastra. Niedawno ogłoszono, że funkcja ta wkracza do głównej gałęzi i już wkrótce będzie możliwy wybór między pełnym Service Mesh w tradycyjnym wydaniu z sidecar proxies lub też w lżejszym już bez nich. Możliwe, że to spowoduje większą adopcję Istio, bo obecnie wciąż nie jest to priorytet wśród wielu organizacji używających Kubernetesa. Prostsze i lżejsze Istio Ambient może ten trend zmienić.\nUważaj na Alpine Linux w kontenerach Używasz Alpine do tworzenia obrazów kontenerów? To uważaj, bo może Cię czekać niemiła niespodzianka. Jak opisuje to jeden z użytkowników z małym rozmiarem tej popularnej dystrybucji linuksowej wiąże się duża niedogodność. Jak wiadomo Alpine używa innej podstawowej biblioteki C - zamiast standardowej w innych dystrybucjach Glibc używa ono muslc. I tu się zaczyna problem. Otóż okazuje się, że muslc nie wspiera odpytywania serwerów DNS po TCP, a jedynie po UDP. Niby nic groźnego, a jednak objawia się to czasem dość nieprzyjemnie. Otóż jeśli zapytanie nie zmieści się w 512 bajtach to aplikacje działające na Alpine nie będą w stanie dostać odpowiedzi, bo normalnie resolver DNS przyłączyłby się na zapytanie po TCP, a to jest w Alpine niemożliwe!\nUważaj zatem na Alpine i rozważ Debiana lub Ubuntu. Ich rozmiar jest może ciut większy, ale unikniesz takich i innych niespodzianek związanych z konsekwencjami wyboru innej biblioteki C przez twórców Alpine.\nMulti-cluster prosty jak nigdy dotąd Wpadłem na ciekawy projekt Clusternet, który pomaga łączyć wiele klastrów. To kolejne obok Submariner rozwiązanie ułatwiające tworzenie rozwiązań multi-cluster. Temat jest bardzo ciekawy i osobiście widzę duży potencjał tego typy oprogramowania. Szczególnie, gdy konieczne jest zarządzanie wieloma klastrami w rozwiązaniach hybrydowych lub super krytycznych klastrach rozpostartych na wiele regionów gdzie wysoka dostępność jest kluczowa. Bardzo długo społeczność czeka na stabilizację oficjalnego projektu kubefed, który wciąż nie wyszedł z bety. Z chęcią poleciłbym ten projekt właśnie, ale jak widać jest już sporo alternatyw. Jeśli nie chcesz spinać klastrów przez Service Mesh to warto zobaczyć te wspomniane alternatywy.\nMniejszy wybór dla rozwiązań Kubernetes na on-prem Na tą wiadomość trafiłem z dużym opóźnieniem, ale jest ona na tyle ważna, że postanowiłem jej poświęcić kilka chwil. Jedna z opcji na instalację Kubernetes poza chmurą zniknęła pod koniec tamtego roku. VMware postanowił wycofać Tanzu Community Edition. Co prawda jest opcja “zabawy” z Tanzu Kubernetes Grid, ale tylko do celów niekomercyjnych. Szkoda, bo to była naprawdę ciekawa opcja dla tych co nie chcą samodzielnie wszystkiego sklejać z użyciem kubeadm. Realnie jest teraz już niewiele opcji w wyborze zautomatyzowanej dystrybucji. Jeśli nie chcesz płacić to pozostaje Ci RKE2 od Ranchera lub EKS Anywhere od Amazona. A najlepszą opcją dla tych z budżetem jest wciąż OpenShift ( OKD jako darmowa alternatywa tylko dla odważnych).\nIstnieją mniejsze projekciki, ale nie zdobyły one jakiegoś uznania społeczności i nie wiadomo czy nie znikną. To co łączy RKE2 i EKS Anywhere to poważni gracze stojący za tymi projektami. O ile Amazon może kiedyś zdecydować o skasowaniu swojego projektu to wydaje mi się to mało prawdopodobne - projekt naprawdę się rozrósł i jako jeden z niewielu wspiera automatyzację instalacji na bare-metal. Za RKE2 stoi SuSe, które podobnie jak Red Hat stawia robi z tego swój flagowy produkt. Czasy kiedy SuSe Linux był dobrym biznesem już dawno minęły i coraz więcej osób szuka alternatyw do produktu Red Hata.\nCo robisz jeśli Kubernetes Ci nie pasuje? Piszesz własne rozwiązanie Potrzebujemy innowatorów i wizjonerów. Bez nich nie byłoby Apple, Google, Tesli i innych. To oni wprowadzają rewolucyjne rozwiązania i idą często pod prąd. A dlaczego o tym piszę? Ponieważ takich wizjonerów jest wbrew pozorom całkiem sporo. Każdy z nich chciałby powtórzyć sukces Steve’a Jobsa. Niektórzy chcą tego tak bardzo, że nie tylko ubierają się jak on, ale też robią wszystko, łącznie z posuwaniem się do oszustwa (przypadek Elizabeth Holmes i startupu Theranos jest chyba najbardziej dobitnym przykładem). Jednym z wybitnych ludzi, którzy już zmienili krajobraz IT jest niejaki David Heinemeier Hansson - twórca Ruby On Rails, rajdowiec i przedsiębiorca.\nOtóż po tym jak jedna z jego organizacji wycofała się z chmury teraz ogłosili, że również wycofują się z Kubernetesa. Jest to tym bardziej odważny ruch, że postanowili napisać własne rozwiązanie MRSK (BTW - to chyba najbardziej ascetyczna strona projektu jaką kiedykolwiek widziałem). Wybrali, że idą swoją ścieżką. Motywują to dostosowaniem swojego rozwiązania do ich środowiska opartego na bare-metal i zyskiem czasu potrzebnego do wdrożenia aplikacji (20 sekund zamiast rzekomych kilku minut).\nDoceniam odwagę i naprawdę podziwiam Davida. Jest on fenomenalnym wizjonerem i też autorem książki “Rework”, która bardzo lubię. Nie wiem tylko czy nie widzimy tutaj syndromu Not Invented Here. Z pewnością mają ludzi i zasoby, aby utworzyć taki soft od zera, ale szczerze to nie jest to według mnie dobre rozwiązanie z kilku powodów. Przede wszystkim jest już dobra alternatywa do Kubernetes i jest to Nomad. Bez problemu dałoby się go łatwo przystosować i wykorzystać bogate funkcje jego schedulera. Faktycznie Kubernetes przez to, że jest uniwersalny może być ociężały. Po drugie swoje rozwiązanie opierają na Dockerze, który jest już wypierany przez containerd lub CRI-O i traktowany jako rozwiązanie zbyt ciężkie co jest paradoksem, bo chcieli mieć coś lżejszego. W dzisiejszych czasach jest już naprawdę ciężko wyjść z czym innowacyjnym w tej kategorii. Projektów jest mnóstwo (obecnie ponad 2000 zgrupowanych przez CNCF) i życzę sukcesów każdemu kto chce włożyć swoją cegiełkę do tego ekosystemu. Ja z kolei czekam na kolejną rewolucję na miarę cloud czy Kubernetes.\n","tags":["cloud","docker","istio","kubernetes","nomad","openshift","rancher","tanzu"],"title":"Newsletter #65 - Coraz mniej dystrybucji Kubernetes i niektórzy z niego rezygnują"},{"categories":["newsletter"],"date":"March 10, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/64/","section":"newsletter-archive","summary":"Zacznę dzisiaj od tego, że moje newslettery są jakieś inne. Dlaczego? Otóż zajrzałem do inne popularnego newslettera, wysyłanego przez osobę z branży i stwierdziłem, że chyba jestem dziwny. Otóż w tamtym było mnóstwo linków do artykułów podczas gdy ja się w moich rozpisuję.\nPogodziłem się chyba z moją dziwnością i jednak stwierdziłem, że tego nie zmienię. Uważam, że generowanie “suchych” linków zostawię automatom, które będą to robić lepiej.\nJa natomiast wciąż zostawię to miejsce dla treści pisanych osobiście (bez ChatGPT - obiecuję!), które są dla mnie ważne i też dotyczą technologii, ale też tematów wokoło.\nDlaczego nie kręcę nowych wideo na YouTube Bardzo bym chciał, aby pojawiały się one cyklicznie na moim kanale i trochę jest mi z tym źle, że nie dodaję tam nic nowego ostatnio.\nTo jest związane jednak z trudną decyzją, którą podjąłem. Ja po prostu nie mam czasu, bo przygotowuję mój kurs “Kubernetes po polsku”. Podjąłem się tego zadania i jest ono naprawdę duże oraz złożone. Zajmuje większość mojego czasu i musiałem podjąć też różne inne decyzje, aby skupić się tylko na tym. To dlatego, że …\nWybieram skupienie, ale to nie takie łatwe W przeszłości “łapałem wiele srok za ogon” i czułem jak nie jest to dla mnie efektywne. Oczywiście słyszałem o tym jak warto się skupić na jednej rzeczy, ale trochę mi zajęło w końcu zrozumienie tego i zaaplikowanie u siebie.\nTak, jestem jednowątkową jednostką i czas to wykorzystać. Posiadanie takiego jednego punktu skupienia sprawia, że mój umysł jest w stanie analizować i pracować nad tematem kiedy ja realnie nie pracuję. Zdarza mi się bowiem, że nie robiąc nic wpada mi do głowy kolejny pomysł na usprawnienie. Gdybym miał wiele tematów to możliwe, że też miałbym nowe pomysły, ale dotyczącego któregoś z innych wątków.\nNajtrudniejsze jest jednak powiedzenie NIE dla innych możliwości. Poza kręceniem wideo musiałem też wstrzymać inne moje aktywności. Odmawiam udziału w konferencjach (poza tą jedną, na którą się wybieram za tydzień), nie prowadzę szkoleń i robię wszystko, aby skupiać się na przygotowaniu kursu.\nA dlaczego to takie trudne? Ponieważ jako ludzie o wiele bardziej obawiamy się utraty czegoś niż zdobycia nowych rzeczy czy też usprawnienia. To znany efekt FOMO. Tak po prostu działamy i dlatego ja świadomie podejmuję te trudne decyzje, bo dzięki temu jestem w stanie łatwiej okiełznać ten naturalny strach.\nKluczowy jest rytm Przygotowanie dobrego wideo wymaga czasu. Nie lubię materiałów o niczym i dlatego moje przygotowania trochę trwają. To jednak zaburza mój rytm pracy nad innymi, dłuższymi rzeczami (czyli obecnie kursem).\nZ tego samego powodu nie prowadzę obecnie szkoleń. To niby tylko 2 lub 3 dni, ale tak naprawdę wychodzę z rytmu i powrót do niego zajmuje mi kolejny dzień lub więcej.\nA czy to oznacza, że jadę jak maszyna? Absolutnie nie. Nie oszukuję się, że wszystkie dni będę produktywny przez 100% czasu. Często przeznaczam sobie poniedziałki na mniejsze tematy, ustalanie planów i przygotowanie mentalne do skupienia się na tym jednym, najważniejszym temacie.\nZacząłem też śledzić czas, który spędzam na poszczególnych czynnościach (używam Toggl Track). Dzięki temu będę wiedział ile realnie trwa przygotowanie takiego kursu, na co idzie najwięcej czasu i jak to w przyszłości zoptymalizować. To jest też doskonały motywator, gdyż teraz czuję wewnętrzną potrzebę, aby posiedzieć nad tematem i mieć to “udokumentowane”.\nPrzy tak dużych tematach liczy się bardziej to czy dołożyłem kolejne godziny pracy niż jakieś kamienie milowe. Te w końcu zostaną zrealizowane, ale skupiam się bardziej nad samym faktem skupionej pracy niż na rozkminianiu czy to jest najbardziej efektywne. To jest mój cel behawioralny, bo mam największy wpływ na moje działanie niż na efekt. Ten liczę, że będzie satysfakcjonujący, ale nie osiągnę go bez setek godzin pracy.\nCo z tego może być dla ciebie Nie katuj się, że jednego dnia nie udało Ci się zrobić zbyt wiele. Tak czasem bywa i możliwe, że jutro może być bardziej odpowiedni dzień. Jeśli warunki nie sprzyjają, nie możesz osiągnąć skupienia to wypełnij go mniejszymi tematami, zastanów się co faktycznie będziesz robić jak już usiądziesz do tego dużego tematu.\nWiększość dużych i ważnych rzeczy wymaga długiej i ciężkiej pracy. To więcej niż takie pojedyncze strzały do zrealizowania w jeden dzień - to często tygodnie, miesiące, a nawet i lata wytężonej pracy. Oczywiście rozbite na mniejsze części nie jest to takie przerażające, ale potrzebujesz utrzymywać to skupienie, gdyż będą wpadać tematy poboczne.\nRób swoje, nawet jeśli wymaga to odrzucenia innych projektów - zacznij kończyć niż wciąż zaczynać nowe rzeczy. Owszem, to nie jest łatwe i czasem lepiej coś przerwać w trakcie (“fail often, fail fast” jak mawiają fani Agile), ale dowożenie do końca daje olbrzymią satysfakcję. Później możesz zbudować na tym pewność siebie i nauczyć się jak robić to lepiej, bardziej efektywnie w przyszłości. Nie osiągniesz tego przerywając wciąż na starcie.\nPodobno wytrwałością da się osiągnąć naprawdę wiele. Ja to wciąż sprawdzam, ale jeśli tyle ludzi, którzy osiągnęli sukces to powtarzają to coś musi w tym być.\n","tags":["biznes","devops","kariera","rozwój-osobisty"],"title":"Newsletter #64 - Dlaczego nie kręcę nowych wideo na YouTube"},{"categories":null,"date":"March 7, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/17/","section":"podcast","summary":"Czy każdy może zostać Cloud Architektem? Z tym pytaniem zwróciłem się do jednej z niewielu osób w Polsce z tytułem AWS Cloud Hero - Karoliny Boboli.\nPorozmawialiśmy o wielu ciekawych aspektach budowy kariery w chmurze - od tematów czysto technicznych aż po te mniej.\nPosłuchaj, aby dowiedzieć się:\n🔷 Czy poprzednia kariera “nie-w-IT” może pomóc czy też wręcz przeciwnie?\n🔷 Jakie są najważniejsze czynniki dla rozwoju kariery w obszarze Cloud i DevOps?\n🔷 Czym jest metoda “bohatera na białym koniu” i czy się sprawdza?\n🔷 Jaki obszar według Karoliny jest jednym z trudniejszych w chmurze?\n🔷 Czy Kubernetes w chmurze to dobry pomysł?\n","tags":["aws","cloud",null],"title":"17 - O tym czy każdy może być Cloud Architektem z Karoliną Boboli"},{"categories":["newsletter"],"date":"February 28, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/63/","section":"newsletter-archive","summary":"Wszyscy piszą o ChatGPT to i ja stwierdziłem, że dorzucę moje obserwacje w kontekście DevOps i wiedzy na ten temat, którą udało mi się zdobyć.\nTo dość nietypowe, bowiem DevOps nie jest bezpośrednio z tym związany, ale jak pokazuje ten artykuł od OpenAI narzędzia typu Kubernetes doskonale wspierają proces budowy takich rozwiązań. Nie wspominając już o roli MLOps czy AIOps.\nCzy ChatGPT to rewolucja, która zmieni wszystko? Faktycznie, wszędzie o tym pełno i już niedługo dawniej eksperci od bitcoina będą się teraz mienić ekspertami od AI.\nDla mnie AI to kolejne narzędzie. Faktycznie, hype jest olbrzymi i niewątpliwie to zmieni bardzo dużo. Podobnie jak wiele zmienił cloud czy kontenery i Kubernetes.\nTakie treści jak ten newsletter wkrótce mogą być pisane w większości przez AI. Ja wciąż piszę samodzielnie, ale od niedawna zacząłem dyktować, aby przyśpieszyć i ułatwić sobie pracę (BTW - dyktowanie z Apple ssie, ale Google jest naprawdę całkiem w porządku).\nNajszybciej takie rozwiązania wpłyną na małą garstkę ludzi, którzy obecnie są milionerami, a zapewne wkrótce staną się miliarderami. Taki Google może przestanie być liderem technologii i skorzysta na tym Microsoft, który zainwestował w OpenAI.\nRozwiązania typu ChatGPT dostaniemy zapewne w produktach, które ułatwią sprzedaż, będą z nami rozmawiać (takie lepsze czatboty), a usługi staną się bardziej interaktywne.\nTo po prostu będzie bardzo dobre narzędzie, ale znowu nie rozwiąże wszystkich problemów.\nCzego nie zrobi AI? Taki ChatGPT posiada dostęp do olbrzymiej ilości danych, które zostały opublikowane w internecie. Nie zapominajmy, że jest to tylko olbrzymi zbiór danych prezentowanych w lepszej niż dotychczas w formie. Łatwiej w ten sposób łączy te przysłowiowe kropki z całego internetu, ale nie wynajmiesz go do ogarniania całej swojej roboty.\nNikt nie zatrudni AI zamiast ludzi – firmy zaczną zatrudniać ludzi, którzy znają to narzędzie, aby działać po prostu sprawniej.\nNajtrudniejsze rzeczy takie jak branie odpowiedzialności i podejmowanie decyzji nie jest związane z wiedzą. To pozostanie wciąż domeną ludzi.\nTo jeszcze nie jest czas na Skynet z Terminatora – do tej wizji mamy wciąż daleko. Ja bym bardzo chciał, aby taki ChatGPT pomógł mi rozwiązać problem, na którym spędziłem ostatnio trzy dni (opisywałem tą historię w ostatnim newsletterze).\nNo bo do czego innego to wykorzystać?\nJak wykorzystać ChatGPT? Tak szczerze? To ja jeszcze do końca nie wiem. Już teraz może wygenerować ci yamle do Kubernetesa, napisze skrypt i może coś nawet bardziej złożonego.\nTak jak wspomniałem, to jest genialne skumulowanie wiedzy i chciałbym, aby to był też taki lepszy stackoverflow.\nChciałbym, aby tak było, bo wówczas będzie możliwe szybsze uczenie się i rozwiązywanie problemów. Ja wciąż jednak mam przekonanie o olbrzymiej roli myślenia – według mnie myślenie wciąż będzie w cenie. Ale to nie jedyny element, którego AI nie zastąpi.\nCzy jest się czego obawiać? Gdybym napisał że nie to bym skłamał. Całkiem możliwe, że za kilka lat wiedza przeze mnie posiadana stanie się łatwo zastąpialna. Możliwe, że tak jak teraz ja dyktuję ten newsletter to wkrótce możliwe będzie stawianie całych środowisk przeprowadzając krótki dialog z czatbotem.\nCzy zatem wszyscy wyjedziemy w Bieszczady paść owce lub otworzymy franczyzę Żabki zamiast siedzieć przy tych komputerach?\nMoże nie będzie tak źle, gdyż już wieszczono koniec pewnych zawodów. W końcu cloud i automatyzacja miały zabrać pracę admina, a powstał DevOps i mnóstwo nowych perspektyw.\nTo co mam teraz z tym zrobić? Jest oczywiste, że świat idzie do przodu i należy obserwować zachodzące zmiany. Nie oznacza to jednak konieczności radykalnej zmiany – rób dalej swoje. Kontynuuj rozwój i dokładaj kolejne elementy do kapitału swojej kariery.\nI pamiętaj o bardzo, ale to bardzo ważnej rzeczy – nawet jak świecisz zajefajnością to wciąż liczy się zaufanie i umiejętność rozwiązywania problemów oraz dostarczania realnej wartości.\nMoże ChatGPT pozwoli Ci zbudować nowe umiejętności, ale budowanie zaufania i rzetelności wciąż pozostaje Twoją odpowiedzialnością.\nJestem przekonany o tym, że wciąż będziemy opierać się na relacjach, bo po prostu tak zbudowany jest nasz mózg. On jeszcze się nie przystosował do tak błyskawicznych zmian (wciąż myśli, że biegamy po dżungli) i dlatego też może być to przytłaczające.\nAle spokojnie - wkrótce i ta technologia spowszechnieje, a my znajdziemy dla niej miejsce i zastosowanie.\n","tags":["chatgpt","devops","edukacja","kariera","kubernetes","rozwój-osobisty"],"title":"Newsletter #63 - Czy ChatGPT zabierze nam pracę?"},{"categories":null,"date":"February 25, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/15/","section":"podcast","summary":"Co roku zbieram takie informacje, aby łatwiej układać swoją ścieżkę rozwoju w tym obszarze. Tym razem zrobiłem to inaczej i obok technologii pojawiają się bardzo ważne umiejętności nietechniczne. W końcu DevOps to nie tylko narzędzia, prawda?\nPoniżej lista, ale i tak najlepiej obejrzyj całość lub to co Cię najbardziej interesuje.\nKubernetes Cloud Terraform CI/CD Programowanie Projektowanie API Bezpieczeństwo Everything as Code Aktywne słuchanie Zwięzłe prezentowanie 💪 Zbuduj umiejętność #1 z moim kursem: https://kubernetespopolsku.pl\n","tags":["kubernetes","devops"],"title":"15 - Top 10 umiejętności DevOps"},{"categories":["newsletter"],"date":"February 21, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/62/","section":"newsletter-archive","summary":"To jest prawdziwa historia, wiesz - taka oparta o faktach. Nikt nie zginął, no chyba, że liczymy te zaginione dni z mojego życia. Ale do rzeczy.\nJak wiesz jestem w trakcie przygotowywania kursu “Kubernetes po polsku” i jednym z jego elementów są moduły PRO. Poruszają one zaawansowane funkcje Kubernetes, których chyba nikt nigdy w kursie nie umieszczał. Są czasem dość odjechane, ale bardzo ciekawe i przydatne w średnich i dużych środowiskach.\nJedną z takich funkcji umieściłem w programie i w ramach moich prac postanowiłem to przetestować. Nawet nie wiedziałem jak bardzo intensywne te testy się okażą.\nMoje środowisko Do testów mam swój lab, a raczej kilka jego konfiguracji. Oto z czego się one składają:\nKubeadm z własną konfiguracją do stawiania Kubernetes Czasem używam też k3s ze względu na szybsze stawianie węzłów (ale jako Control Plane odpada) Mam konfiguracje maszyn wirtualnych Vagrant na Macu z Virtualbox i na stacji z Windows 11 z Hyper-V Używam też Packera do budowania własnych obrazów dla Vagrant - to zdecydowanie przyspiesza mi stawianie środowisk Okazjonalnie też stawiam instancje w chmurze GCP i mam do tego kod Terraform - przydaje się do większych testów Czyli jak widzisz mam wszystko czego potrzebuję. A do czego tego użyłem?\nA miało być tak pięknie - dzień 1 W ramach kursu chcę wytłumaczyć jak użyć zaawansowanych reguł kierowania ruchem do instancji, aby aplikacje komunikowały się szybciej. I jedną z takich funkcji jest Topology Aware Hints. Dokumentacja jest, przykładów brak. Ale co to dla mnie!\nPrzystąpiłem do testów i… klops. Nie działa. Tylko dziwne komunikaty w logach. Nie ukrywam - strasznie się zirytowałem! Przeszukałem Internet i nic - najwidoczniej niewiele osób tego jeszcze używa. Podwójna szkoda - nie wiedzą co tracą, a ja wciąż nie mam rozwiązania. Brak przykładów zmusił mnie do zajrzenia do kodu źródłowego kontrolera odpowiadającego za obsługę tej funkcji. Jedyne czego się dowiedziałem to to, że część informacji nie jest logowana. To na koniec dnia zwiększyłem gadatliwość komponentu kube-controller-manager o jeden (-v2) w ramach ustawień kubeadm. Nie pomogło za wiele.\nBliżej, a jednak wciąż tak daleko - dzień 2 Logi tylko nakierowały mnie bliżej, ale wciąż nie miałem tego co chciałem. Teraz wiedziałem, że szukałem nie tam gdzie powinienem. I powiem szczerze, że nie znając zasad działania Kubernetes pewnie bym tak utknął. I tak spędziłem cały dzień eksperymentując na różnych konfiguracjach i czytając kod źródłowy (szczególnie ten fragment). Aż w końcu doznałem pierwszego olśnienia - ta funkcja nie działa na węzłach control plane! Usunąłem labelki z moich trzech węzłów i… dalej nic. Ale po dodaniu kolejnego węzła (ta funkcja nie działa jeśli nie ma wystarczającej ilości węzłów w strefach) już witałem się z gąską - w logachv pojawiła się wyczekiwana informacja, że funkcja “ Topology Aware Hints has been enabled” . No w końcu! Przystąpiłem do testów, uruchomiłem przykładowe aplikacje w podach, puściłem ruch, a tu niespodzianka - dalej nie działa. Znowu zawiedziony kończyłem dzień i coś co miało zająć tylko chwilę przedłuża się na kolejny dzień. W tym momencie miałem odpuścić i następnego dnia przejść do kolejnego tematu.\nAlbo ja albo on - dzień 3 “Nie tym razem - nie mogę tak tego odpuścić” - pomyślałem kiedy zaczynałem kolejny dzień. Ze świeżym umysłem zasiadłem i odpaliłem po raz chyba 50-ty moją konfigurację maszyn i sprawdziłem reguły ruchu wystawiane przez kube-proxy na iptables (nagrałem o tym wideo).\nI co? Wszystko tam wyglądało dobrze - ruch powinien trafiać tylko do części aplikacji, a moje testy nadal pokazywały, że ruch idzie do wszystkich. Dodatkowo licznik tych reguł wskazywał na 0, czyli w ogóle ruch nie trafiał do tych łańcuchów. Ale dlaczego?\nI kolejne olśnienie - w mojej konfiguracji użyłem Cilium do obsługi sieci. A Cilium jest bardzo fajne, ale działa w oparciu o eBPF i również manipuluje regułami iptables. Podmieniłem Cilium na Calico i.. Ruszyło! W końcu po trzech dniach z ulgą przyjąłem fakt, że to nie ja, nie sam Kubernetes, a Cilium coś namieszał.\nI tak spędziłem 3 dni na diagnozowaniu tego błędu. Sporo przy okazji jeszcze się dowiedziałem o innych komponentach, ale to już może historia na kolejny raz.\nCzego się nauczyłem Wszystko może być lekcją, nawet (a może szczególnie) jak kosztuje Cię 3 dni i kupę irytacji. Oto co wyciągnąłem z tego dla siebie:\nNawet jak myślisz, że już dużo wiesz to mogą czekać Cię niespodzianki - po prostu bądź gotowy do ciągłej nauki, nawet jak Cię to wkurza Dokumentacja ma sens, szczególnie dobra, ale przykłady mają jeszcze większy sens - łatwiej jest wklejać, nawet na początku bezmyślnie, niż samodzielnie rozkminiać Nawet jak nie jesteś developerem to umiejętność czytania kodu ma wymierne korzyści - w tym przykładzie ewidentnie bym poległ, gdybym nie potrafił zrozumieć co jest pod spodem Pomagaj społeczności - ja w wyniku tych eksperymentów zgłosiłem bug na GitHubie i liczę, że oszczędzi to innym cennych dni i niepotrzebnych nerwów Cilium jest wspaniałe, ale ten nowy sposób działania (ePBF) może wymagać czasu na dostosowanie do wszystkich zaawansowanych funkcji Kubernetes I oczywiście - nigdy się nie poddawaj, ale też daj sobie czasu. Mogłem się poddać po pierwszym lub drugim dniu, ale odpoczynek pozwolił mojemu umysłowi na kolejną rundę i ze świeżym spojrzeniem udało mi się dotrzeć do celu. ","tags":["cloud","docker","kubernetes","packer","rancher","terraform","vagrant"],"title":"Newsletter #62 - Trzy dni z życia wyjęte, czyli moja historia diagnozowania małego problemu"},{"categories":["ebooks"],"date":"February 15, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/ebooks/przystan-kubernetes/","section":"ebooks","summary":"Nie taki deployment straszny Jedna rzecz to słyszeć o tym jaki Kubernetes jest fajny, mieć nawet dostęp do klastra, a druga to móc go faktycznie sprawnie użyć.\nPrzedstawiam Ci ebooka, który krok po kroku pokaże Ci jak zbudować i wdrożyć aplikację na klaster Kubernetesa. I to nie jest jeden z tych banalnych tutoriali – moje wskazówki pozwolą Ci zarządzać aplikacją jaką możesz spotkać w realnej pracy.\nJest ona złożona z backendu i frontendu, a narzędzia, które przedstawiam mogą spokojnie posłużyć Ci do pracy na środowisku produkcyjnym.\nCo osiągniesz z tym ebookiem Szybko zbudujesz powtarzalne obrazy kontenerów Uruchomisz aplikacje na lokalnym klastrze oraz na dowolnym zdalnym Uruchomisz bazę danych w kontenerze i połączysz ją z aplikacją Przechowasz hasła w bezpieczny, zaszyfrowany sposób w repozytorium gita Łatwo dostarczać konfigurację do aplikacji bez konieczności utrzymywania ręcznie obiektów ConfigMap Budować i uruchamiać aplikacje na klastry o architekturze ARM! Liczy się czas Użyj odpowiednich narzędzi i technik, aby ułatwić sobie codzienną pracę z Kubernetesem. Ten e-book oszczędzi Ci wiele godzin, dni, a może i tygodni układania tego samodzielnie w spójną całość!\n","tags":["kubernetes","friko","deployment","skaffold","docker","kustomize","sops","minikube","helm"],"title":"(PL) Przystań Kubernetes"},{"categories":["newsletter"],"date":"February 14, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/61/","section":"newsletter-archive","summary":"Dzisiaj krótki wstęp. Obecnie pracuję intensywnie nad kursem, ale wciąż trzymam rękę na pulsie i oto lista nowości ze świata Cloud Native.\nPodcast “Rozchmurzony” #16 Tydzień temu wyszedł kolejny odcinek mojego podcastu. Muszę przyznać, że go trochę zaniedbałem, ale obiecuję poprawę 🙂 Tym razem ja i Łukasz Ciećwierz usiedliśmy porozmawiać o technologii, ale też o trudnych tematach miękkich takich jak:\n🔷 Jak regulowana przepisami branża finansowa używa chmury publicznej? 🔷 Czym jest Cloud Center of Excellence? 🔷 Jak testy osobowości mogą pomóc w pracy zespołu? 🔷 Czy konflikt zawsze jest niepożądany? 🔷 Czym jest zasada FUKO? 🔷 Czym Scrum się sprawdza w zespołach cloudowych?\nPodcast do odsłuchania na większości platform oraz również bezpośrednio na stronie odcinka.\nAKS już nie jest za friko? Do niedawna Microsoftowy Kubernetes w chmurze (AKS) był prawie za friko. To prawie oznaczało, że nie płaciło się za utrzymanie części Control Plane (czyli tej najtrudniejszej do utrzymania). Do teraz, bo Microsoft ogłosił, że to się zmieni. Od teraz są dwie wersje - jedna wciąż jest darmowa (rekomendowana do 10 węzłów), a druga płatna i taka bardziej “pro” (ma między innymi autoskalowanie klastra). Czyżby na AKS było zbyt dużo klastrów, które mogą zarabiać dla MS? Tego nie wiem, ale z dużych graczy to chyba teraz jedynie Oracle ma darmowy control plane dla Kubernetes.\nBędę 15 marca na CloudFest w Bydgoszczy Chcesz przybić piątkę i pogadać ze mną? To tak się składa, że będę na konferencji CloudFest w Bydgoszczy 15 marca. Dla tych co mają blisko lub po prostu to nie problem pojawić się wtedy w Bydgoszczy mam darmowe zaproszenia - odezwij się do mnie bezpośrednio (np. odpisz na tego maila), a możesz zaoszczędzić trochę grosza.\nCiekawe wyniki ankiety CNCF Opublikowano niedawno wyniki ankiety CNCF. Ja wyłapałem najciekawsze rzeczy i pozwoliłem sobie na dodanie do nich kilku przemyśleń.\n79% ankietowanych używa kontenerów na produkcji To już wiedzieliśmy - kontenery są wszędzie. Co ciekawe jednocześnie “tylko” 64% używa Kubernetesa na produkcji. Zastanawiam się co z kontenerami robią inni. Czyżby Docker Swarm jeszcze żył? A może są to samodzielnie kontenery zarządzane w stylu “odpal i zapomnij” (+opcja automatycznego restartu)? Są dwa największe wyzwania w adopcji Kubernetes Pierwsze mnie nie zaskoczyło - to bezpieczeństwo. Po prostu organizacje boją się nowego i nawet jak mają te Kubernetesy, klastry, “devopsy” to i tak boją się o ich bezpieczeństwo. Wydaje mi się, że to stale będzie wyzwanie - niezależnie od technologii. W końcu najbezpieczniejsze systemy to takie, które są wyłączone i nieużywane. Drugie wyzwanie jest dla mnie zaskoczeniem - to brak szkoleń. W dobie tutoriali, dokumentacji i innych materiałów to nadal najwidoczniej nie jest to dobrze wytłumaczony obszar. Tym bardziej cieszę się, że mój kurs rozwiąże ten problem dla szukających dobrego materiału do rozwoju tych umiejętności. Większość używa wielu klastrów I choć da się zrobić tzw. “Miękką izolację” na pojedynczym klastrze to jednak oddzielne klastry rządzą. Szczególnie jeśli się je łatwo stawia i nimi zarządza, a to nie zawsze jest oczywiste. Wyobrażam sobie, że te organizacje jednocześnie wykorzystują zarządzanie klastrami przez kod - terraform i dobry GitOps to dobrana para do tego zadania. Duże organizacje rzadko używają tylko chmury publicznej Im większa organizacja tym większa szansa, że będzie używane przynajmniej rozwiązanie hybrydowe lub tylko on-prem. Startupy i małe organizacje mogą działać tylko w chmurze, ale duzi gracze nie odpuszczają on-prem. On nie odejdzie i model hybrydowy zagości już na stałe. A wiadomo, że Kubernetes doskonale unifikuje takie środowiska więc zupełnie się temu nie dziwię. Adopcja OPA spada i Argo rośnieAdopcja Open Policy Agent maleje i tutaj się nie dziwię. Sam wybrałbym coś natywnego jak Kyverno lub Kubewarden. OPA jest uniwersalny, ale jego język rego nie należy do najprzyjemniejszych. Co do Argo to jak najbardziej zrozumiałe - to doskonałe projekty, bo pod Argo rozumiem nie tylko rozwiązanie GitOps, ale grupę innych projektów. Nadal uważam, że Argo CD jest świetne do dużych projektów, ale do mniejszych rozważyłbym Flux CD (szczególnie jeśli nie zależy Ci na GUI). ","tags":["aks","cncf","kubernetes"],"title":"Newsletter #61 - Ciekawe wyniki ankiety CNCF"},{"categories":null,"date":"February 10, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/16/","section":"podcast","summary":"Czy użycie chmury publicznej w branży finansowej to standard czy wciąż wyjątek? Jak budować zwinne zespoły, które ją obsługują?\nTen odcinek to ciekawa rozmowa. Ja i Łukasz Ciećwierz usiedliśmy porozmawiać o technologii, ale też o trudnych tematach miękkich. Posłuchaj, aby dowiedzieć się:\n🔷 Jak regulowana przepisami branża finansowa używa chmury publicznej?\n🔷 Czym jest Cloud Center of Excellence?\n🔷 Jak testy osobowości mogą pomóc w pracy zespołu?\n🔷 Czy konflikt zawsze jest niepożądany?\n🔷 Czym jest zasada FUKO?\n🔷 Czym Scrum się sprawdza w zespołach cloudowych?\nMateriały, które wspomniane są w tym odcinku:\nKsiążka “5 dysfunkcji pracy zespołowej” https://lubimyczytac.pl/ksiazka/4508138/piec-dysfunkcji-pracy-zespolowej-opowiesc-o-przywodztwie Książka “Głaskologia” - https://lubimyczytac.pl/ksiazka/198919/glaskologia-faktyczne-reguly-motywowania-i-rozumienia-motywacji Książka “Porozumienie bez przemocy” - https://lubimyczytac.pl/ksiazka/4942459/porozumienie-bez-przemocy-o-jezyku-zycia Film “Three Identical Strangers” - https://www.imdb.com/title/tt7664504/ ","tags":["biznes","cloud","perfekcjonizm"],"title":"16 - O zwinnym budowaniu zespołów cloudowych z Łukaszem Ciećwierzem"},{"categories":["newsletter"],"date":"February 7, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/60/","section":"newsletter-archive","summary":"Koniec tego szaleństwa. Chodzi o tryb przedsprzedaży, z którego wychodzę i powracam do standardopwego trybu publikowania treści.\nDzisiaj standardowa porcja informacji ze świata Cloud Native. Styczeń się już skończył, niedługo Walentynki, później Wielkanoc, wakacje i oby do Bożego Narodzenia.\nPrzedsprzedaż zakończona - zaczynam realizację kursu Udało się - liczba sprzedanych dostępów w przedsprzedaży pozwoli mi zrealizować mój nowy, profesjonalny kurs “Kubernetes po polsku”!\nTo był ciężki tydzień podczas którego prowadziłem 4 spotkania LIVE, odpowiadałem na mnóstwo maili, ogarniałem małe awarie systemu płatności, ale satysfakcja jest ogromna.\nNiesamowicie cieszę się, że znalazłem 120 osób, które mi zaufały! Ja się już nie mogę doczekać aż będę publikował te zaawansowane części (moduły PRO), bo z tego widzę to jest to wciąż wiedza niedostępna. Oczywiście do czasu publikacji mojego kursu 🙂\nWkrótce wyślę do tych wszystkich osób wiadomości i otworzę odrębne kanały dla naszej komunikacji.\nA jeśli nie chcesz przegapić premiery gotowego kursu to stworzyłem specjalną listę - możesz się na nią zapisać na stronie kursu.\nCzym jest IDP? Od dawna wiedziałem, że Kubernetes jest stworzony do platform. A teraz ma to już swoją nazwę i nabiera więcej szczegółów.\nMowa o koncepcji platform Internal Developer Platform (IDP). A dlaczego jest to ważne?\nPonieważ to skupia w sobie wiele elementów i nadaje jeszcze większy sens umiejętnościom związanych z Kubernetes.\nWszystkie klocki zaczynają się w logiczną całość i widać jak najlepiej wykorzystać projekty Cloud Native.\nNa jednym z ostatnich LIVE opowiadałem szczegółach tej koncepcji. Obejrzyj nagranie, gdzie dowiesz się między innymi:\n🔷 Czym jest IDP?\n🔷 Po co powstało i jaki ma cel?\n🔷 Komu to w ogóle jest potrzebne?\n🔷 Z czego się składa?\n🔷 Jak wyglądała (i pewnie nadal wygląda) praca bez platformy IDP?\n🔷 W jaki sposób Kubernetes wpisuje się w jej tworzenie?\nCilium jest szybkie i może służyć za LoadBalancer Cilium jako CNI jest doskonałym wyborem dla zarządzania ruchem w klastrze. To już wiedzieliśmy wcześniej, ale okazuje się, że jest nowy obszar do zagospodarowania - to load balancing ruchu wchodzącego do klastra.\nHetzner przeprowadził testy, gdzie sprawdzono przepustowość, opóźnienia i obciążenie CPU przez Cilium. Potwierdzono tylko, że Cilium wymiata, a to jeszcze nie koniec.\nDodatkowo ten ciekawy artykuł opisuje jak Cilium może zastąpić projekt MetalLB do przydzielania adresów z zewnętrznej puli dla serwisów typu LoadBalancer. Sama funkcjonalność jest opisana tutaj i wygląda zacnie.\nWyszła nowa wersja OpenShift Dawno nie pisałem o OpenShift, a tu niedawno opublikowano wersję 4.12.\nNiektórzy mówią, że to najlepszy i również najdroższy Kubernetes dla dużych organizacji, w szczególności tych, które chcą budować platformy (może nawet IDP?) na on-prem.\nA co do zmian to jest ich sporo i nie będę ich wymieniał - odsyłam do wpisu na blogu. Moją uwagę przykuł ciekawy ficzer “Network Observability Operator”, który bardzo ciekawie obrazuje przepływ ruchu sieciowego w klastrze.\nDo tego jest możliwość rozszerzania GUI (OpenShift i tak ma najlepszą konsolę webową do zarządzania) poprzez dynamiczne moduły.\nRed Hat faktycznie stworzył swój flagowy produkt opierając go o Kubernetes i całe mnóstwo operatorów. Niektórzy jednak i tak używają go jedynie jako Kubernetesa bez korzystania z wielu dodatków i w ten sposób mogą mieć środowisko w pełni kompatybilne z innymi klastrami Kubernetes (np. EKS/AKS/GKE).\n","tags":["cilium","idp","kubernetes","openshift"],"title":"Newsletter #60 - Czym jest IDP i dlaczego Cilium wymiata"},{"categories":["pl"],"date":"January 26, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/pl/nagrania-ze-szkolenia-10-bledow-pracy-z-kubernetes/","section":"pl","summary":"No i po szkoleniu. Omówiłem na nim \u0026ldquo;10 najczęściej popełnianych błędów w pracy z Kubernetes\u0026rdquo;. Było treściwie i konkretnie.\nPoruszone tematy obejmowały problemy, które mogą mieć poważne konsekwencje. Te z kolei z reguły ciężko wyeliminować jeśli trafią one na środowisko produkcyjne. Oto obszary, które zaadresowałem na szkoleniu:\nkontrola dostępu niezawodność bezpieczeństwo aplikacji i platformy codzienne praktyki pracy z klastrami Zobacz sam - nagranie jest już dostępne. Odwiedź tą stronę i po zarejestrowaniu dostaniesz link do niego.\n","tags":["autoskalowanie","devops","docker","edukacja","kubernetes","prometheus","security"],"title":"Nagrania ze szkolenia \"10 błędów pracy z Kubernetes\""},{"categories":["newsletter"],"date":"January 24, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/59/","section":"newsletter-archive","summary":"Czy ja już kończę z Kubernetesem?\nWysyłam ten newsletter co tydzień i często (naprawdę się ograniczam) piszę coś o Kubernetes. Nie zamieszczę tutaj statystyk, bo aż się boję policzyć ile razy użyłem go w ostatnim roku przynajmniej.\nMoim celem jest dostarczenie Ci rzetelnych informacji i dlatego też w końcu przygotowałam materiał o tym kiedy to nie jest dobry pomysł pchać się z nim na siłę.\nA jeśli już go używasz to mam dla Ciebie ciekawe szkolenie w tą środę o 19:00. Szczegóły poniżej.\nKiedy Kubernetes nie ma sensu To dla Twojej wygody streszczę Ci te przypadki:\nJak masz/używasz chmury publicznej ORAZ: Nie potrzebujesz multi-cloud ani hybrydowego podejścia Używasz specyficznych usług dostępnych u Twojego dostawcy i nie potrzebujesz stawiać tego samodzielnie Masz pełną (ale taką prawdziwą) automatyzację swojego środowiska Istnieje w organizacji praktyka konserwatywnego podejścia oparta o politykę, prawo lub inne, niezależne czynniki Jeśli nie używasz Cloud tylko on-prem ORAZ: Zbudowałeś platformę w trybie self-service (na podstawie chmury prywatnej lub inaczej) Twoja organizacja pracuje nad produktem/usługą wykorzystującą niskopoziomowo sprzęt (nie dotyczy GPU) Sieć (np. opóźnienia) i jej istniejąca konfiguracja jest bardzo specyfycznia i naprawdę ciężko to sparować z kontenerami (m.in. wyzwania z wychodzącymi adresami IP) Masz dziwny storage, czyli taki, który nie ma sterownika CSI dla Kubernetes Masz mała skalę, czyli: Aplikacja jest prosta i to jeszcze nie czas myśleć o tych wspaniałościach Kubernetesa Masz mało instancji i nie zapowiada się na więcej Nie chcesz tracić zasobów na obsługę Control Plane - może się nie opłacać przy małym środowisku Masz mały ruch i prawdopodobnie nigdy nie skorzystasz z autoskalowania Masz nietypowe oprogramowanie, czyli: Dostarczane z zewnątrz i licencja nie przewiduje uruchamiania tego na kontenerach Trudno (ale naprawdę to musi być duże wyzwanie) się konteneryzuje Działa tylko na Windows Rzadko jest potrzeba aktualizacji Czynniki ludzkie Nie ma zespołu (chyba najczęściej) Za mało czasu na naukę, a terminy gonią Zespół/organizacja boi się ryzyka związanego z ewentualnymi błędami (głównie z niewiedzy) Szczegóły pokazałem na ostatnim LIVE, który możesz zobaczyć tutaj.\n","tags":["kubernetes"],"title":"Newsletter #59 - Kiedy Kubernetes może nie być dla Ciebie"},{"categories":["pl"],"date":"January 16, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/pl/top-10-umiejetnosci-devops/","section":"pl","summary":"Co jest potrzebne, aby pracować w obszarze DevOps? Jakie konkretne umiejętności, technologie i narzędzia trzeba znać?\nW tym artykule pokażę Ci jasną ścieżkę rozwoju DevOps dla inżynierów, architektów i ekspertów. Artykuł podzieliłem na 3 części:\nW pierwszej z nich skupię się na narzędziach dla inżynierów DevOps. W drugiej części opowiem o umiejętnościach dla architektów DevOps. W ostatniej zdradzę, co jest wymagane, aby zostać ekspertem DevOps. Umiejętności inżynierskie Zacznijmy od umiejętności inżynierskich. Oto 5 narzędzi technicznych i umiejętności, które są niezbędne dla inżynierów DevOps - zaczynając od juniorów, a kończąc na bardziej seniorskich stanowiskach.\n1 - Kubernetes Oczywiście, że Kubernetes jest numerem jeden, a jakże by inaczej! Nie tylko dlatego, że to moje ulubione narzędzie, ale przede wszystkim dlatego, że stał się technologią, która zmieniła branżę IT w ciągu ostatnich kilku lat.\nJest niemal wszędzie i jest używany przez większość największych firm. Jest wszechobecny, ponieważ może być używany w chmurze w modelu Kubernetes-as-a-service lub w środowiskach on-prem z wykorzystaniem zwykłych serwerów.\nKubernetes łączy wiedzę z wielu dziedzin. Nie jest to więc pojedyncza umiejętność, ale grupa wielu umiejętności.\nAby dobrze poznać Kubernetes musisz nauczyć się Linuksa - w końcu Kubernetes można postrzegać jako po prostu grupę linuksowych serwerów widocznych i zarządzanych poprzez API i to wszystko!\nMusisz wiedzieć jak działa Linuks i jak go skonfigurować na serwerze oraz jak używać narzędzi zawartych w każdej dystrybucji (np. sed, find, awk, top, ps, kill, itd.). Z Linuksem przychodzi kolejna technologia związana z Kubernetesem - to kontenery. Dlatego powinieneś wiedzieć czym jest kontener i jak działa Docker lub inny silnik kontenerowy.\nPonadto inżynier DevOps musi rozumieć linuksowe sieci, aby móc tworzyć klastry, load balancery, kontrolować ruch i używać Service Mesh.\nZanim narodził się Kubernetes, to właśnie Linuks i chmura były podstawowymi technologiami wykorzystywanymi w DevOps. Teraz przeniosło się to na kontenery oparte na Linuksie.\nPo co więc w ogóle uczyć się Kubernetesa?\nJeśli go znasz, to po prostu łatwiej i szybciej skonfigurować autoskalowalne środowiska, które reagują na zmieniające się wykorzystanie aplikacji.\nŁatwiej jest też zabezpieczyć obciążenia, ponieważ z Kubernetes otrzymujesz wiele dodatkowych narzędzi (np. opartych na technologii ePBF), a także dlatego, że kontenery są szybsze w aktualizacji.\nDzięki Kubernetesowi będziesz mógł tworzyć jeszcze bardziej złożone środowiska multi-cloud, a co ważniejsze - dużo łatwiej stworzysz rozwiązania hybrydowe. Ten ostatni scenariusz wykorzystania staje się ostatnio coraz bardziej popularny.\nAle czy wiesz, co jest prawdziwym celem Kubernetesa i powodem, dla którego stał się tak popularny? Jest nim szybkość wdrożeń. I przez szybkość mam na myśli cały proces od opublikowania kodu z repozytorium git aż do wdrożenia na środowisko produkcyjne.\nTo dlatego deweloperzy kochają Kubernetes i dlatego Twoim zadaniem jest zapewnienie bezproblemowego, jak najłatwiejszego wykorzystania go w Twojej organizacji.\nOd osób pracujących jako inżynierowie DevOps lub architekci oczekuje się eksperckiej wiedzy na temat Kubernetes - inni (tj. programiści) będą zwracać się do nich o pomoc, jak efektywnie wykorzystać jego funkcje.\nPo prostu nie wyobrażam sobie nowoczesnego DevOps bez Kubernetes. Koniec. Kropka.\n2 - Cloud Teraz druga technologia, która jest niezbędna dla DevOps. Jednak chmura to technologia, która może być dostarczana przez konkretnego dostawcę (np. AWS, Azure lub GCP), ale także nowe podejście do budowania środowisk IT. Niektórzy nazywają to cloud-native i pod tym pojęciem kryje się wiele technologii, jak wspomniany wcześniej Kubernetes.\nWracając jednak do pojęcia, które wszyscy znamy jako Cloud. Jedno jest pewne - w gruncie rzeczy wszystkie chmury są do siebie podobne. Wystarczy więc poznać przynajmniej jednego dostawcę chmury dość dobrze, aby móc korzystać z pozostałych.\nZacznij od zdobycia podstawowej wiedzy.\nMusisz znać część dotyczącą sieci. Prawie wszyscy dostawcy używają koncepcji Virtual Private Cloud (w skrócie VPC lub też podobne nazwy), aby odizolować Twoje maszyny i usługi na poziomie sieci. Musisz wiedzieć, jak nimi zarządzać, zabezpieczać ruch za pomocą polityk ruchu sieciowego (tzw. “security groups”) i tworzyć różne strefy prywatne i publiczne.\nWszyscy dostawcy chmury mają jakiś rodzaj zarządzania dostępen i tożsamościami (w skrócie IAM), aby kontrolować dostęp do swoich API dla użytkowników i maszyn.\nA skoro już mówimy o maszynach - niezależnie od tego, jak dostawcy chmury je nazywają (maszyny wirtualne, instancje czy też zasoby obliczeniowe), są to po prostu znan nam serwery linuksowe. Trzeba wiedzieć, jak je tworzyć, dystrybuować między strefami dostępności i przygotowywać obrazy, aby umożliwić korzystanie z mechanizmów automatycznego skalowania.\nAby systemy były odporne, musisz nauczyć się korzystać z odpowiednich technologii pamięci masowych - w tym pamięci blokowych dołączanych bezpośrednio do instancji oraz pamięci obiektowych wykorzystywanych przez aplikacje i do wielowarstwowych rozwiązań backupowych.\nWszystko to jednak kosztuje, czasem nawet bardzo dużo. Więc jednym z twoich obowiązków jest nauczenie się, jak skutecznie kontrolować koszty usług. I uwierz mi - to może być czasem podstępne i trudne do ogarnięcia.\nJak więc kontrolujesz swoje środowiska chmurowe? Używasz tych wymyślnych interfejsów webowych tylko po to, aby uzyskać przegląd swojego środowiska. W innych przypadkach używasz API i to powinien być twój główny sposób interakcji z chmurą.\nWiesz, jaką zabawną rzecz w chmurze i Kubernetes zauważyłem po pracy z nimi przez wiele lat? Ucząc się Kubernetesa łatwiej jest zrozumieć chmurę i odwrotnie! Zauważysz, że istnieją wspólne koncepcje z subtelnymi różnicami. Na przykład w chmurze używasz maszyn wirtualnych jako podstawowych komponentów dla usług, podczas gdy w Kubernetes używasz zamiast tego kontenerów. Jednak nadal wchodzisz z nimi w interakcje poprzez API, ustawiasz reguły RBAC, kontrolujesz ruch, skalujesz instancje, balansujesz ruch oraz ustawiasz metryki i logowanie.\nWięc ucz się chmury najpierw jako technologii, a następnie jako bardziej uniwersalnego podejścia cloud-native.\n3 - Terraform Przejdźmy do kolejnej fascynującej technologii. Jest nią Terraform. Jeśli o nim nie słyszałeś to musiałeś przespać ostatnie kilka lat lub jesteś totalnie nowy w DevOps.\nProjekt ten jest jednym z najbardziej znanych ze stajni HashiCorp, w skład którego wchodzą również Consul, Packer czy Vault.\nJest to oprogramowanie numer jeden w dziedzinie automatyzacji. Najczęściej jest wykorzystywane do automatyzacji środowisk chmurowych, ale nie tylko do tego.\nTerraform jest bardziej uniwersalny, bo jego rozszerzalna architektura umożliwia korzystanie z tzw. providerów, co rozszerza jego zastosowanie na prawie każdy rodzaj oprogramowania, które ma jakieś API (np. GitLab, GitHub, Grafana, Zabbix - jest ich ponad 2 tysiące!).\nWłaściwie Terraform może zastąpić inny projekt, który był szeroko stosowany w obszarze zarządzania infrastrukturą - Ansible.\nKorzystałem z Ansible, ale moim zdaniem nie jest to najszybszy i najwygodniejszy w obsłudze (zwłaszcza w rozwiązywaniu problemów) kawałek oprogramowania. Nie jest też całkowicie deklaratywny jak Terraform i uważam, że w większości przypadków można użyć Terraforma z jego dostawcami (providerami) i modułami.\nOprócz providerów społeczność Terraform stworzyła wiele przydatnych modułów, które zmniejszają pracę związaną z automatyzacją wszystkich rzeczy.\nModuły te mogą być szczególnie przydatne, gdy nie znasz specyfiki danego API chmury. Terraform wchodzi w bezpośrednią interakcję z API i dlatego wymaga dość dogłębnej wiedzy na jego temat, a tak możesz sobie skrócić drogę i odroczyć dogłębne poznanie API na później.\nTerraform jest tak dobry w automatyzacji infrastruktury chmurowej, że Oracle wybrał go jako podstawowe narzędzie do automatyzacji w swojej chmurze OCI. Moim zdaniem to tylko potwierdza pozycję lidera Terraform jako narzędzia do automatyzacji. I jak wspomniałem - nie tylko automatyzacji środowisk chmurowych, ale także różnych komponentów instalowanych na szczycie zautomatyzowanej infrastruktury.\nWraz z innym projektem HashiCorp - Packer - może posłużyć do automatyzacji każdego skrawka infrastruktury chmurowej. I przez chmurę rozumiem zarówno środowiska publiczne jak i prywatne, ponieważ Terraform wspiera również platformy on-prem - jeśli masz OpenStack lub vSphere uruchomione na swoich serwerach to Terraform pomoże Ci zautomatyzować je w deklaratywny sposób.\nA kiedy nadejdzie czas, możesz wykorzystać swoje umiejętności, aby zautomatyzować provisioning chmury publicznej na dowolnym dostawcy. Koniec z własnościowymi narzędziami, i interfejsami graficznymi - jedno narzędzie do automatyzacji ich wszystkich.\nJedną z najważniejszych części DevOps jest automatyzacja, a Terraform jest rozwiązaniem, które musisz znać, aby budować wysoce zautomatyzowane środowiska.\n4 - CI/CD Czy wiesz, kiedy deweloperzy doceniają posiadanie dobrych inżynierów DevOps na pokładzie swojego zespołu? Kiedy pomagają im uczynić procesy wdrażania bezproblemowymi i to bez większego wysiłku.\nA osiąga się to poprzez stworzenie procesów Continuous Integration i Continuous Deployment lub Delivery.\nJednym z najważniejszych zadań dla inżynierów DevOps jest przygotowanie infrastruktury oraz procesów CI/CD, aby zespoły deweloperskie mogły skupić się na\u0026hellip; tworzeniu najlepszego kodu, jaki tylko potrafią.\nNie możesz pomóc deweloperom w tworzeniu lepszego kodu, ale możesz zapewnić, że mają wszystko, czego potrzebują, aby go ulepszyć, bez spędzania zbyt wiele czasu na grzebanie w różnych częściach infrastruktury.\nDzięki automatyzacji wdrażania szybciej możliwe jest uruchomienie różnych procesów przed ujawnieniem tego wspaniałego kawałka oprogramowania użytkownikom końcowym. Procesy te obejmują pakowanie oprogramowania w artefakty, kontenery lub obrazy maszyn wirtualnych, a następnie ich testowanie. Testy te zapewniają, że oprogramowanie jest wolne od poważnych błędów, luk bezpieczeństwa lub innych potencjalnych wad.\nZaufaj mi - programiści nie chcą spędzać czasu na poznawaniu szczegółów infrastruktury i tego, jak te wszystkie kontenery, load balancery, API chmury i maszyny wirtualne współdziałają ze sobą. Oni chcą po prostu tworzyć swój niesamowity kod.\nA im mniej interakcji międzyludzkich jest w tym procesie, tym lepie/szybciejj. Żadnych ticketów i żadnych prywatnych wiadomości na Slack - oni chcą platformy, która po prostu działa.\nWięc które oprogramowanie powinieneś wybrać, aby nauczyć się tworzyć te potoki CI/CD? Właściwie to nie ma znaczenia, naprawdę! Wybierz dowolne, który jest używane w Twojej organizacji lub po prostu jest wygodniejsze, lepsze dla Ciebie.\nMój preferowany silnik CI/CD to Jenkins, ale tylko dlatego, że używam go od wielu lat i nauczyłem się wykorzystywać go do budowania prawie każdego, nawet najbardziej złożonego potoku. Jednak nie jest to najłatwiejszy kawałek softu.\nMoże w Twoim przypadku GitLab CI lub GitHub Actions mogą być lepsze i przede wszystkim łatwiejsze do nauczenia. Może wybierzesz Tekton, gdy będzie już wystarczająco dojrzały, ponieważ jest to projekt zaprojektowany z myślą o Kubernetes.\n5 - Język programowania Ostatnia część od strony inżynierskiej to nie kolejny projekt - to coś, co pozwala je buduwać.\nAby zostać dobrym inżynierem DevOps musisz wiedzieć jak połączyć ze sobą wszystkie klocki, które do tej pory wymieniłem.\nPotrzebujesz jakiegoś języka programowania do tworzenia skryptów lub usług (więcej o tym później).\nPolecam naukę tych trzech w tej konkretnej kolejności.\nZacząłbym od Basha. Nie jest to język programowania per se, ale najpopularniejsza powłoka znajdująca się w prawie każdej dystrybucji Linuksa. Więc czy to maszyna wirtualna on-prem, serwer bare-metal, instancja chmury, węzeł Kubernetes, czy kontener - powłoka Bash już tam jest.\nMożna jej używać do interakcji z systemem lub do tworzenia skryptów. Bash ma wszystko, czego potrzebujesz do mniejszych zadań - począwszy od pętli, warunkow, a nawet wbudowanych wyrażeń regularnych.\nBash jest również często używany do tworzenia plików Dockerfile z definicją obrazów kontenerów lub w skryptach cloud-init wykonywanych przy uruchamianiu instancji chmury. Dzięki niesamowitemu narzędziu o nazwie curl możesz nawet wchodzić w interakcje z różnymi REST API, a wykorzystując inne dostępne polecenia możesz zautomatyzować procesy na dość przyzwoitym poziomie.\nJednak Bash jest daleki od doskonałości i może być niewystarczający dla bardziej złożonych scenariuszy.\nDlatego w dalszej kolejności zainteresuj się Pythonem. Jest to najpopularniejszy język i również dość łatwy do nauczenia. Kiedy Bash i curl nie wystarczą, Python ze swoją prostotą może wybawić Cię z kłopotów. Jest bardzo wydajny, gdy mamy do czynienia z danymi i komunikacją z usługami poprzez API. Obsługa błędów, moduły i testy - to rzeczy trudne do zaimplementowania w czystym Bashu.\nPython jest zwykłym językiem programowania i można w nim napisać wszystko, co tylko dusza zapragnie. Dzięki tak wielu dostępnym bibliotekom można nawet stworzyć własny operator Kubernetesa. Jest to więc zdecydowanie pierwszy wybór dla inżynierów DevOps. Ale nie jedyny.\nCzasami potrzebujesz czegoś więcej. Może chcesz napisać własny operator Kubernetes za pomocą Native SDKs lub stworzyć wtyczki dla Terraform lub Vault. Wtedy proponuję użyć Golang.\nJest to język pierwszego wyboru dla środowisk cloud-native. Tam, gdzie liczy się szybkość i rozmiar wybierz Go. Jest często używany do tworzenia obrazów kontenerów jednoplikowych, które działają na klastrach Kubernetes.\nGolang jest jeszcze bliżej warstwy OS i chociaż jego składnia jest bardziej złożona (szczególnie w porównaniu do Pythona), to nadal jest on dość łatwy do nauczenia.\nUmiejętności architekta Tak więc to były umiejętności wymagane od inżyniera DevOps, a teraz przejdźmy do umiejętności architekta DevOps.\nWyróżniłem trzy takie umiejętności i skupiają się one na odpowiednim projektowaniu platform. Aby zostać architektem DevOps trzeba mieć umiejętności inżynierskie i dużo szersze doświadczenie w pracy z nowoczesną infrastrukturą.\nO ile dostęp do StackOverflow czy nawet systemów AI takich jak ChatGPT może pomóc Ci w rozwiązywaniu codziennych zadań jako inżynier, o tyle nie uczynią Cię one architektem. Potrzebujesz intuicji, która jest rozwijana przez lata praktyki i wymyślania pomysłów na ulepszenia i optymalizacje.\n6 - Projektowanie API Pierwszą umiejętnością jest projektowanie API. Teraz, gdy wiesz już, jak działają wszystkie to komponenty, musisz przełożyć tę wiedzę na oprogramowanie.\nNie mówię, że musisz zostać architektem oprogramowania, ale dla architekta DevOps nie wystarczy tylko wiedzieć, jak używać narzędzi. Musisz zacząć automatyzować wszystkie rzeczy w inteligentniejszy i bardziej zunifikowany sposób. Musisz ukryć złożoność wewnętrznych prac za zunifikowanym API.\nW skrócie - inżynierowie korzystają z API, podczas gdy architekci mogą projektować nowe.\nNajprostszym przykładem jest wzorzec projektowy operatora Kubernetes. Napisanie nowego operatora to tak naprawdę zaprojektowanie nowego API. Nie jest to również takie trudne, ponieważ Kubernetes został zaprojektowany tak, aby był rozszerzalny poprzez zapewnienie Custom Resource Definition i SDK do tworzenia kontrolerów.\nW ten sposób można osadzić swoją wiedzę w oprogramowaniu i dostarczyć ją jako usługę. To właśnie definiuje zaawansowany DevOps - automatyzacja z samoobsługą za pomocą API.\nPodobnie możesz rozszerzyć Terraform, pisząc własne providery.\nOczywiście istnieją scenariusze, w których będziesz musiał napisać swoją usługę od zera i to właśnie tam przydaje się twoja wiedza w Pythonie lub Golangu. Istnieje wiele frameworków, które pomogą ci zbudować twoje API (np. Flask, Gin i Revel).\nUważam, że ta forma automatyzacji jest dużo bardziej dojrzała. Umiejętność projektowania nowych API jest wymagana do budowania złożonych systemów na znacznie większą skalę. Nie wszystko można zrobić za pomocą istniejących narzędzi i w tych scenariuszach wiedza w tym zakresie jest kluczowa.\n7 - Bezpieczeństwo Teraz porozmawiajmy o często zaniedbywanym temacie - bezpieczeństwie. Tak, bezpieczeństwo od zawsze było \u0026ldquo;najwyższym\u0026rdquo; priorytetem w wielu organizacjach, ale myślę, że często bardziej chodzi mówienie co powinno być zrobione, niż o smutną rzeczywistość tego, co faktycznie jest robione.\nDlatego ta ważna praca jest częścią obowiązków architekta DevOps. I jeszcze raz - nie chodzi o narzędzia, ale o realny wpływ na bezpieczeństwo systemów pracujących wewnątrz organizacji.\nAby utrzymać bezpieczeństwo systemów trzeba pracować nad dwoma obszarami: nauczyć się odpowiednich technologii i praktyk, a także upewnić się, że te praktyki są w organizacji stosowane. Żadne narzędzie nie będzie wystarczająco dobre, jeśli nie ma świadomości i współpracy osadzonej w kulturze organizacji.\nMogłem umieścić ten obszar bezpieczeństwa w umiejętnościach inżynierskich i rzeczywiście wszyscy inżynierowie powinni umieć sprawić, aby systemy były bezpieczne. Rola architekta jest jeszcze ważniejsza - musi on pracować również nad aspektami nietechnicznymi.\nA czym jest część techniczna? Z perspektywy DevOpsa chodzi głównie o umieszczenie praktyk bezpieczeństwa w kodzie. W dawnych czasach chodziło głównie o niezliczoną ilość dokumentów opisujących jak zabezpieczyć systemy - teraz chodzi o opisanie tego w procesach rozwoju, wdrażania i utrzymania.\nCzyli zaczynając od prostych rzeczy jak OWASP Top 10 poprzez znane praktyki typu “ least privilege principle” , uwierzytelnianie wieloskładnikowe (MFA), audyty itp.\nW przypadku Kubernetesa chodzi też o wykorzystanie dostępnych metod jak profile seccomp i SElinux dla kontenerów, automatyczne skanowanie artefaktów aplikacji i obrazów kontenerów czy egzekwowanie najlepszych praktyk na poziomie API za pomocą tzw. admission kontrolerów (np. OPA czy Kyverno).\nMógłbym wymienić dziesiątki projektów, które skupiają się na bezpieczeństwie dla wszystkich typów środowisk. Ale powtórzę jeszcze raz - to nie narzędzia zabezpieczą Twoje systemy, ale podejście, które jest częścią kultury.\nI uważam, że jest to zadanie dla architekta DevOps lub architekta DevSecOps.\n8 - Wszystko w kodzie Wraz z bezpieczeństwem powiązana jest kolejna bardzo ważna praktyka, która jest kluczowa dla architektów DevOps. Jest to utrzymywanie wszystkiego jako kodu. Innymi słowy - przejście od operacyjnego podejścia do pracy z systemami do ich projektowania i umieszczania każdego elementu w oprogramowaniu.\nOstatnio GitOps pojawił się jako praktyka zarządzania środowiskami Kubernetes i na pewno podąża za tym podejściem, ale ja widzę to szerzej. Uważam, że jest to obowiązkowe dla wszystkich części DevOps.\nTo zmusi cię do myślenia w innych, bardziej zaawansowanych kategoriach.\nSkalowalność jest możliwa tylko wtedy, gdy obrazy maszyn wirtualnych lub kontenerów są dostępne, a proces ich pieczenia jest przedstawiony w kodzie.\nPomyśl o powtarzalności - czy uważasz, że jest ona osiągalna bez zakodowania infrastruktury, procesów CI/CD i wspomnianego bezpieczeństwa?\nŁatwość, z jaką wszystkie kluczowe części platformy mogą być aktualizowane tylko poprzez zmianę kilku linii kodu, również znacząco wzmacnia jej bezpieczeństwo.\nNie zapominaj też o testowaniu. Dzięki temu, że wszystko jest utrzymywane w postaci kodu, każda zmiana może być przetestowana i łatwo odwrócona. Wymaga to pisania scenariuszy testowych, ale to niewielki wysiłek w porównaniu z korzyściami, jakie przynosi.\nTak więc, aby osiągnąć wszystkie te rzeczy i przenieść zarządzanie platformą na następny poziom, musisz umieścić wszystko w repozytorium git. Oddzielić zarządzanie infrastrukturą od rozwoju aplikacji, zwiększyć przejrzystość, umożliwić rollbacki i umożliwić łatwe eksperymentowanie z nowymi funkcjami.\nUmiejętności eksperckie Zostały jeszcze dwie umiejętności, o których chcę powiedzieć. Są to umiejętności nietechniczne lub tzw. miękkie. Zdecydowałem się oznaczyć je jako umiejętności eksperckie, aby podkreślić jak są one ważne i jednocześnie tak rzadko używane.\nCzy to oznacza, że należy się ich uczyć po poprzednich? Wręcz przeciwnie - uważam, że należy je rozwijać jak najwcześniej w trakcie swojej kariery. Szybko odkryjesz (jeśli jeszcze tego nie zrobiłeś), że narzędzia nie mają aż tak dużego znaczenia i są rzeczy o wiele ważniejsze. Są one jednak dużo trudniejsze do opanowania, ale z czasem przyniosą Ci niesamowite rezultaty.\n9 - Aktywne słuchanie Prawdziwy powód, dla którego te eksperckie umiejętności są tak ważne, widać na poniższym diagramie.\nZaczynasz od uczenia się przez działanie, wdrażania małych rozwiązań i wykonywania ręcznych zadań, a potem powoli zaczynasz zauważać, że rzeczywiście praca z kodem jest bardziej efektywna i wręcz nie wyobrażasz sobie pracy bez tego.\nNastępnie bierzesz udział w coraz większej ilości spotkań, podczas których Twoja wiedza, jakkolwiek doceniana, nie ma aż tak dużego znaczenia. Musisz zacząć słuchać i to słuchać bardzo uważnie.\nTo wydaje się proste, prawda? No cóż, nie do końca. Ile razy zdarzyło Ci się uczestniczyć w dyskusji, kiedy ktoś mówił, a Ty w myślach już przygotowywałeś sprytną odpowiedź lub robiłeś coś, zamiast naprawdę słuchać tego, co druga osoba próbowała przekazać?\nMusisz nauczyć się wyłapywać istotne elementy z długich monologów lub gorących dyskusji.\nPodczas spotkań zadawaj właściwe i jasne pytania. Staraj się zrozumieć, zanim intuicyjnie zaczniesz oceniać i proponować własne rozwiązania.\nPraktyka skutecznego słuchania jest niedoceniana, prawdopodobnie dlatego, że wymaga cierpliwości i pokory. Dlatego powinna być umiejętnością, którą stale rozwijasz.\nBędzie więcej systemów AI takich jak ChatGPT, ale nic, naprawdę nic i nigdy nie zastąpi empatycznego słuchania. W ten sposób budujesz relacje i znajdujesz problemy, które warto rozwiązać Twoją wiedzą i energią.\n10 - Zwięzła prezentacja Ostatnia umiejętność idzie w parze z poprzednią. Aby zostać uznanym za eksperta musisz umieć przedstawić swoje pomysły w sposób najbardziej przejrzysty i przekonujący.\nPodobnie jak w diagramie rozwoju kariery z poprzedniego punktu - im bardziej stajesz się starszy, tym więcej spotkań bierzesz pod uwagę. Ale co robisz podczas tych spotkań? Czy tylko słuchasz? Od Ciebie, jako eksperta w swojej dziedzinie, oczekuje się, że będziesz prezentował lub aktywnie uczestniczył w dyskusji.\nNie da się być jej wartościowym uczestnikiem bez wcześniej zdobytej wiedzy i doświadczenia. Podejście \u0026ldquo;fake it till you make it\u0026rdquo; zostanie szybko obalone.\nCo robią prawdziwi eksperci? Oni jasno i prosto prezentują złożone pomysły i koncepcje. Wiedza nie wystarczy, ale jest warunkiem koniecznym. Wykorzystujesz swoją wiedzę, aby poinformować innych ludzi o możliwych scenariuszach lub wpłynąć na ich decyzję.\nAby zrobić to dobrze, nie możesz tak po prostu opowiedzieć w szczegółach wszystkiego, co wiesz - to przytłaczające dla innych i przynosi efekt przeciwny do zamierzonego.\nZwięzła prezentacja to umiejętność, którą można i moim zdaniem trzeba rozwijać, aby skutecznie wpływać i występować w roli prawdziwego eksperta.\nTa umiejętność jest kluczowa do użytku wewnątrz organizacji, a niektórzy mogą ją wykorzystywać zewnętrznie podczas prezentacji publicznych. Nie każdy ekspert lubi lub chce występować publicznie, ale ludzie doceniają wystąpienia ekspertów. To dlatego, że wiele osób z mniejszym doświadczeniem występuje na konferencjach, ale osoby takie często mają mniej interesujące i inspirujące rzeczy do pokazania.\nJak więc stać się lepszym w zwięzłym prezentowaniu? Z pewnością ćwicz, ale też dbaj o to, czym “karmisz” swój mózg. To efekt tzw. \u0026ldquo;garbage in, garbage out\u0026rdquo; - jeśli spędzasz czas na TikToku, Instagramie, nie czytasz publikacji, nie dajesz wartościowych informacji do przerobienia umysłowi to nie możesz oczekiwać “na wyjściu” równie wartościowych rzeczy.\nNasze mózgi muszą być karmione wartościowymi treściami, aby móc zbudować bazę pod coś, co wyróżnia ekspertów - rozwiązywanie problemów za pomocą intuicji, a nie łatwo dostępnej wiedzy.\nPodsumowanie Kariera w DevOps to według mnie jedna z najciekawszych ścieżek w IT. Nie bez przyczyny wciąż jest niedobór ludzi, którzy są stanie przyswoić odpowiednią wiedzę. Myślę, że dzięki przedstawionym grupom wymagań staje się to przynajmniej o wiele jaśniejsze.\nMam nadzieję, że pomoże to ułożyć swoisty plan rozwoju dla osób pragnących wejść w ten obszar lub rozwijających się w nim dalej.\nPrzygotowałem też specjalną mapę, która pokazuje te umiejętności wraz z dodatkowymi wskazówkami (technologie, projekty, najważniejsze zagadnienia). Może być ona swoistym drogowskazem.\nDostępna jest poniżej (potrzebny email użyty do subskrybcji mojego newslettera)\nSprawdź mapę umiejętności DevOps https://youtu.be/JPZFYY2gen0\n","tags":["cloud","devops","engineer","gitops","jenkins","kariera","kubernetes","rozwój","technology","terraform"],"title":"Top 10 umiejętności DevOps"},{"categories":["articles"],"date":"January 16, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/top-10-devops-skills/","section":"articles","summary":"(You can also watch the video)\nDevOps is a huge area - a mix of technology and culture. So what is required to become a DevOps engineer? What skills are required?\nIn the following parts, I’m going to show you a clear path for DevOps engineers, architects, and experts.\nI have divided the article into 3 parts:\nIn the first one, I will focus on the tools for DevOps engineers. In the second part, I will talk about skills for DevOps architects. And in the last one, I will reveal what is required to become a DevOps expert. Engineer skills Let’s start with engineering skills. These are 5 technical tools that are essential for DevOps engineers - starting from Junior to more senior positions.\n1 - Kubernetes Of course, Kubernetes is number one. Not only because it’s my favorite tool, but most of all because it has become the technology that changed the IT industry over the past few years.\nIt’s almost everywhere and has been adopted by most major companies. It’s ubiquitous as it can be used in the cloud as Kubernetes-as-a-service or the on-prem environments using regular servers.\nKubernetes combines knowledge from multiple areas. So it’s not a single skill but a group of many skills.\nTo know Kubernetes well you need to learn linux - after all, Kubernetes can be viewed as just a bunch of linux servers visible and managed via API, that’s it!\nYou must know how Linux works and how to set it up on a server and how to use the tools included in every distribution (e.g. sed, find, awk, top, ps, kill, etc.).\nWith Linux comes another technology related to Kubernetes - it’s containers. So you ought to know what a container is and how Docker or any other container engine works.\nOn top of that it is required for a DevOps engineer to understand Linux networking to be able to set up clusters, load balancers, control traffic, and use service meshes.\nBefore Kubernetes was born, it was Linux and cloud that had been the primary technologies used in DevOps. Now it has shifted to containers based on Linux.\nSo why learn Kubernetes in the first place?\nIf you know how to use it it’s just easier and faster to set up scalable environments that are responsive to the changing utilization of the apps.\nIt’s also easier to secure workloads as with Kubernetes you get a lot of additional tools (e.g. based on ePBF technology) and also because containers are faster to update.\nWith Kubernetes, you will be able to create even more complex multi-cloud environments and what is even more important - you will create hybrid solutions a lot easier. The latter scenario has become really popular recently.\nBut do you know what is the REAL purpose of Kubernetes and the reason why it has become so popular? It’s the speed of deployments. And by speed, I mean the whole process of getting code from a git repository to the production environment.\nThat’s why developers love Kubernetes and that’s why it’s your job to ensure effortless use of it within your organization.\nPeople working as DevOps engineers or architects are expected to have expert knowledge of Kubernetes - others (i.e. developers) will turn to them for help on how to use its features efficiently.\nI just can’t imagine modern DevOps without Kubernetes. Period.\n2 - Cloud Now here comes the second technology that is essential for DevOps. But this time it’s a tricky part because many companies prefer on-prem environments. However, cloud is a technology that can be provided by a specific vendor (i.e. AWS, Azure, or GCP) but also a new approach toward building IT environments. Some people call it cloud native and this term includes many technologies like the previously mentioned Kubernetes.\nBut getting back to the concept we all know as Cloud. One thing is clear - in fact, all clouds are similar. So all you need to do is get to know at least one cloud provider well enough to use the other ones.\nStart by acquiring fundamental knowledge.\nYou need to know the networking part. Almost all vendors use the concept of Virtual Private Cloud (aka VPC or they use similar names) to isolate your workloads and services on the network level. You must know how to manage them, secure traffic with policies (e.g. security groups) and create various private and public zones.\nAll cloud providers have some kind of Identity and Access Management (IAM for short) to control access to their APIs for users and machines.\nAnd while we’re discussing machines - regardless of how cloud vendors call them (virtual machines, instances or compute resources) they are just good old Linux servers. You need to know how to create them, distribute them among availability zones and prepare (or as some call it “bake”) images to enable the use of automatic scaling mechanisms.\nTo make your systems resilient you need to learn how to use proper storage technologies - that includes block storage attached directly to the instances and object storage used by apps and for multi-tier backup solutions.\nAll of these costs, sometimes a lot. So one of your responsibilities is to learn how to effectively control the cost of the services. And trust me - it can be tricky at times.\nAnd how do you control your cloud environments? You use these fancy web interfaces just to grasp an overview of your environment. In other cases you use API and it should be your primary way of interacting with the cloud.\nDo you know what funny thing about the cloud and Kubernetes I’ve noticed after working with them for many years?\nBy learning Kubernetes it’s easier to understand cloud and vice-versa! You will notice that there are common concepts with subtle differences. For example, in the cloud, you use virtual machines as building blocks for the services while in Kubernetes you use containers instead. However, you still interact with them via API, set RBAC rules, control traffic, scale workloads, load balance traffic and set up metrics and logging.\nSo learn cloud first as technology, then as a more universal cloud-native approach.\n3 - Terraform Moving on to another fascinating technology. It’s terraform. If you haven’t heard of it you must have slept for the last few years or you’re new to DevOps.\nThis project is one of the most known from the HashiCorp suite that also includes Consul, Packer, or Vault.\nIt’s the number one software for automation. It’s mostly used to automate cloud environments but it’s not only for that.\nIt’s more universal, as its pluggable architecture enables the use of 3rd party providers that extends its use to almost any kind of software that has some API (e.g. GitLab, GitHub, Grafana, Zabbix - there are over 2k of them).\nActually, it can replace another project that has been used widely in the infrastructure management area - Ansible.\nI’ve used Ansible a lot, but in my opinion, it’s not the fastest and most convenient to use (especially troubleshoot) piece of software. It’s also not entirely declarative as Terraform and I believe in most cases you can use Terraform with its providers and modules.\nYes, modules. Beside providers Terraform community has created a lot of useful modules that reduce your work of automating all the things.\nThese modules can be especially useful when you don’t know the specifics of the particular cloud API. Terraform interacts with API directly and thus it requires pretty in-depth knowledge of it.\nTerraform is so good at automating cloud infrastructure that Oracle chose it as a primary tool for automation in their OCI cloud. In my opinion, it just confirms the leadership position of Terraform as a tool for automation. And as I mentioned - not only automation of cloud environments but also various components installed on top of the automated infrastructure.\nTogether with another HashiCorp project - Packer - can be used to automate every bit of your cloud infrastructure. And by cloud, I mean both public and private environments as Terraform supports on-prem platforms as well - if you have OpenStack or vSphere running on your servers then Terraform will help you to automate it in a declarative way.\nAnd when the time comes you can use your skills to automate the provisioning of the public cloud on any vendor. No more proprietary tools, and graphical interfaces - one tool to automate them all.\nOne of the most important parts of DevOps is automation and Terraform is the solution you must know to build highly automated environments.\n4 - CI/CD Do you know when developers appreciate having good DevOps engineers onboard their team? When they help them to make their deployment processes seamless and effortless.\nAnd you achieve it by creating Continuous Integration and Continuous Deployment or Delivery processes.\nThat’s right - one of the most important tasks for DevOps engineers is to prepare infrastructure AND CI/CD processes so that development teams can focus on\u0026hellip; creating the best code they can. You can’t help developers create better code but you can ensure they have everything they need to improve it without spending too much time on infrastructure parts.\nWith automated deployment processes it’s faster to start various processes before revealing this magnificent piece of software to the end users. These processes include packaging software into artifacts, containers,s or VM images and then testing them. These tests ensure the software is free of major bugs, security vulnerabilities, or other potential defects.\nTrust me - developers don’t want to spend time learning infrastructure details and how all these containers, load balancers, cloud APIs, and virtual machines interact with each other. They just want to craft their awesome code.\nAnd the less human interaction is involved in the process the better. No tickets and no private messages on Slack - they want a delivery platform that just works.\nSo which software should you choose to learn to create those CI/CD pipelines? Actually, it doesn’t matter, really! Pick any that is used in your organization or just seems more suitable for you.\nMy preferred one is Jenkins, but only because I’ve been using it for many years now and I’ve learned to leverage it to build almost any, even the most complex pipeline. However, It’s not the easiest piece of software.\nMaybe in your case, GitLab ci or GitHub actions can be better and most of all easier to learn. Maybe you’ll choose Tekton when it’s mature enough, as it’s the project designed with Kubernetes in mind.\n5 - Programming language The last part is not another software project - it’s something that builds it.\nTo become a good DevOps engineer you need to know how to connect all of the building blocks I’ve mentioned so far together.\nYou need some programming language to create scripts or services (more on that later). I recommend learning these three ones in that specific order.\nI would start with Bash. It’s not a programming language per se, but the most popular shell found in almost any Linux distribution. So whether it’s an on-prem virtual machine, bare-metal server, cloud instance, Kubernetes node, or a container, the Bash shell is there.\nYou can use it to interact with a system or to create a script. Bash has everything you need for smaller tasks - starting from loops, conditional statements, and even built-in regular expressions.\nBash is also often used to create Dockerfiles with container images definition or in the cloud-init scripts executed at the startup of cloud instances. With an amazing tool called curl you can even interact with various REST APIs and by using other commands available, it is possible to automate your processes on a decent level.\nHowever, bash is far from perfect and can be insufficient for more complex scenarios.\nThen comes Python. It’s the most popular language and quite easy to learn too. When Bash and curl are not enough, Python with its simplicity can save you from troubles. It’s very powerful when dealing with data and communication with services via API. Error handling, modules, and tests - these are the things hard to implement in pure Bash.\nPython is a regular programming language and you can write anything you like. With so many available libraries you can even create your own Kubernetes operator. So it’s definitely the first choice for DevOps engineers. But not the only one.\nSometimes you need something more. Maybe you want to write a Kubernetes operator using Native SDKs or create plugins for Terraform or Vault. Then you might want to use Golang.\nIt’s the language of the first choice for cloud-native environments. Where speed and size matters choose Go. It’s often used to create single-binary container images that run on Kubernetes clusters.\nGolang is even closer to the OS layer and although its syntax is more verbose it’s still quite easy to learn.\nArchitect skills So those were skills required for a DevOps engineer and now let’s move on to DevOps Architect.\nI’ve distinguished three such skills and they are focused on the proper design of platforms. To become a DevOps architect you need to have engineering skills and much broader experience in working with modern infrastructure.\nWhile having StackOverflow or even AI systems like ChatGPT may help you solve day-to-day work as an engineer, they will not make you an architect. You need intuition which is developed over years of practice and coming up with ideas for improvement and optimization.\n6 - API design The first skill is API design. Now that you know how all the building blocks work, you need to put that knowledge into software.\nI’m not saying that you need to become a software architect, but for an architect, it’s not enough to just know how to use the tools. You need to start automating all the things in a smarter and more unified way. You need to hide the complexity of inner works behind a unified API.\nIn short - engineers use APIs while architects design new ones.\nThe simplest example is the Kubernetes operator design pattern. Writing a new operator is in fact designing a new API. It’s also not that hard since Kubernetes is designed to be extensible by providing Custom Resource Definition and SDKs for developing controllers.\nIn that way, you can embed your knowledge in software and provide it as a service. That’s what defines advanced DevOps - automation with self-service using API.\nSimilarly, you can extend Terraform by writing custom plugins.\nOf course, there are scenarios where you will need to write your service from scratch and that’s where your expertise in Python or Golang comes in handy. There are plenty of frameworks that will help you to build your API (e.g. Flask, Gin, and Revel to name a few).\nI find this form of automation much more mature. The skill of designing new APIs is required to build complex systems on a much larger scale. Not everything can be done with existing tools and in those scenarios expertise in that area is crucial.\n7 - Security Now let’s talk about an often neglected topic - security. Yes, security has always been a “top” priority, but I think it’s often more about what should be done rather than the sad reality of what is actually being done.\nThat’s why this important job is a part of DevOps architect responsibilities. And once again - it’s not about the tools but about the real impact on the security of systems working inside an organization.\nTo keep systems secure you need to work on two areas: learn what technology and practices to use and also how to make sure these practices are in use within the organization. No tool will be good enough if there’s no awareness and cooperation embedded in the culture.\nI could have put security in the engineering skills and indeed all engineers should be able to make their systems secure. The architect\u0026rsquo;s role is even more important - they have to work on the non-technical aspects as well.\nAnd what is the technical part? From DevOps\u0026rsquo; perspective, it’s mostly about putting security practices in code. In the old days, it was mostly about a myriad of documents describing how to secure the systems - now it’s about describing it in the development, deployment, and maintenance processes.\nSo starting from simple things like OWASP Top 10 through well-known least privilege principle, Multi-factor authentication, auditing, etc.\nWith Kubernetes, it’s also about using available methods like seccomp profiles and SElinux for containers, automated scanning of the application artifacts and container images, or enforcing best practices on the API level with OPA or Kyverno.\nI could list dozens of projects that focus on security for all types of environments. But I will repeat once again - it’s not the tools that will secure your systems, but the approach that is a part of the culture.\nAnd I believe it’s a job for DevOps Architect or DevSecOps Architect if you will.\n8 - Everything as Code Alongside security comes another very important practice that is crucial for DevOps Architects. It’s keeping everything as code. In other words - moving from operating systems to designing them and putting every piece in software. Recently GitOps has emerged as the practice for the management of Kubernetes environments and sure it follows this approach, but I see it more broadly. I find it mandatory for all parts of DevOps.\nThis will force you to think in other, more advanced terms.\nScalability is possible only when virtual machine or container images are available and the process of baking them is presented in code.\nThink about repeatability - do you think it’s achievable without coding your infrastructure, CI/CD processes, and aforementioned security?\nThe ease with which all crucial parts of the platform can be updated just by changing a few lines of code also significantly strengthens its security.\nAnd don’t forget about testing. With everything kept as code, every change can be tested and easily reverted. This requires writing test scenarios but it’s a small effort compared to the benefits it brings.\nSo to achieve all those things and bring your platform management to the next level you need to put everything in a git repository. You will decouple infrastructure management from app development, increase transparency, enable rollbacks and allow for easy experimentation with new features.\nExpert skills There are two skills left I want to speak about. They are non0-technical or soft skills if you will. I decided to mark them as expert skills to emphasize how important they are and also how rarely used.\nDoes it mean they should be learned after the previous ones? On the contrary - I believe they should be developed as early as possible in your career. You will soon discover (if you haven’t done so already) that tools don’t matter that much and there are things of a lot more importance. They are, however, much harder to master, but will yield incredible results over time.\n9 - Active listening The real reason why these expert skills are so important is visible on the diagram below.\nWhen your career progresses from junior to senior and then to expert.\nYou start with learning by doing, implementing small solutions, and and doing some manual tasks and then slowly you start to notice that indeed, working with code is more efficient and you even master that approach.\nThen you attend more and more meetings during which your knowledge, however appreciated, doesn’t matter that much. You need to start listening and listening very carefully.\nThat seems easy, isn’t it? Well, not exactly. How many times have you been in a discussion when someone was talking and in your mind you were preparing a clever response or you were doing something instead of really listening to what the other person was trying to convey.\nYou must learn to pick up essential elements from lengthy monologues or heated discussions.\nDuring meetings ask the right and clear questions. Try to understand before intuitively start to judge and offer solutions.\nThe practice of effective listening is underappreciated, probably because it requires patience and humility. That’s why it should be the skill you’re developing constantly.\nThere will be more AI systems like ChatGPT, but nothing, really nothing will ever replace empathetic listening. That’s how you build relationships and find the problems worth solving with your expertise and energy.\n10 - Concise presentation The last skill goes together with the previous one.\nTo be recognized as an expert you need to be able to present your ideas most clearly and convincingly.\nLike in the career progress diagram - the more senior you become the more meetings you attend. But what do you do during these meetings? Do you listen only? As an expert in your field, you will be expected to present or actively take part in the discussion.\nIt’s impossible to be a valuable participant without previously gained knowledge and experience. The “fake it till you make it” approach will be quickly debunked.\nWhat do real experts do? They simply present complex ideas. Knowledge is not enough, but it’s a prerequisite. You use your expertise to inform other people about possible scenarios or to influence their decision. And to do it right you cannot dump everything you know on the table - it’s overwhelming and counterproductive.\nConcise presentation is a skill that can be and, in my opinion, must be developed to effectively influence and act as a real expert.\nThis skill is crucial for internal use and some may use it externally during public presentations. Not every expert enjoys or wants to do public speaking, but people appreciate it when they do. It’s because there are many people with less experience at conferences presenting their ideas, but they often are just less interesting\nSo how do you become better at concise presenting? First practice, but also care about what you feed your brain with. It’s the “garbage in, garbage out” effect.\nOur brains need to be fed with valuable content to be able to build up the base for something that distinguishes experts - solving problems with intuition rather than easily available knowledge.\nConclusion That’s it. I hope now you know what is required to become a DevOps Engineer who knows the tools, DevOps Architect who is able to design complex environments or an expert who can help in implementing DevOps practices across organizations.\nUse it to grow your career. The world needs more savvy people to help publish more innovative solutions.\n","tags":["career","cloud","devops","engineer","gitops","jenkins","kubernetes","skills","technology","terraform"],"title":"Top 10 DevOps Skills"},{"categories":["newsletter"],"date":"January 10, 2023","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/57/","section":"newsletter-archive","summary":"Czego miało nie być? Tego konkretnego maila. Napisałem go w ostatniej chwili, bo pomyślałem, że może się komuś przydać.\nOd strony technologii okres poświąteczny to okres stagnacji i niewiele się dzieje. Stąd poświęcam (znowu) na nietechniczne aspekty.\nMógłbym Ci napisać podsumowanie roku 2022 - ile to podcastów mi się udało nagrać, ile wideo nagrałem, ile live`ów przeprowadziłem, który to już newsletter, ale realnie nie ma to znaczenia.\nJeśli czytasz ten newsletter to szukasz czegoś dla siebie. I dzisiaj mam dla Ciebie specjalny temat, bo być może tak jak ja ciężko Ci wrócić do tej szarej rzeczywistości dnia codziennego po Świętach.\n5 pytań na początek roku Wybrałem pięć pytań, na które sam musiałem sobie odpowiedzieć. I nie chodzi o jakieś górnolotne postanowienia, które musisz sobie od razu postawić.\nPytania mają tą specyficzną właściwość, że one “pracują” podczas, gdy nawet o tym nie myślimy świadomie. Dlatego ja bardzo polecam zadawać sobie i innym dobre pytania. Te poniżej dotyczą tego co możesz i co chcesz zmienić w nadchodzącym roku.\nCzy jestem w miejscu, w którym chcę zostać?\nTo z pozoru proste pytanie, ale mi osobiście przysparza wiele problemów. Rodzą mi się wątpliwości co do moich wyborów, a przede wszystkim co do wytrwałości.\nNie jest to łatwe ocenić czy jesteś na właściwej dla siebie ścieżce biorąc pod uwagę Twoje możliwości, a przede wszystkim Twoje wartości.\nCo muszę zrobić, aby to zmienić? **\n** Jeśli to nie to miejsce to co muszę zmienić? Może i u Ciebie jest to długa lista. Nie mam złotej recepty na to, ale mi pomogło w przeszłości wykreślenie kilku rzeczy z takiej listy życzeń.\nPo prostu łatwiej mi koncentrować się na usprawnianiu tego co jest dla mnie naprawdę ważne. Skupienie energii na kilku dosłownie rzeczach, bo jej rozpraszanie ma słabe efekty. Mi trochę to zajęło, aby to w końcu zrozumieć.\nCo mnie blokuje? **\n** U mnie przez bardzo długi czas to był perfekcjonizm. Stawiałem przed sobą nierealne oczekiwania, które nie pozwalały mi nawet wystartować.\nTeraz pracuję nad wytrwałością i ten konkretny mail jest tego przykładem. O mały włos bym go nie napisał i już się usprawiedliwiałem przed sobą. Ale jeśli go czytasz to znaczy, że się nie poddałem i dalej walczę.\nCo mi pomaga? **\n** Jeśli jest coś takiego co Ci pomaga to trzymaj się tego i próbuj wzmacniać. Ja mam w głowie moją wizję i moje cele.\nCzasem może być to coś do czego dążysz, albo wręcz przeciwnie - coś od czego chcesz uciec. U mnie są rzeczy, od których uciekam i też stanowią bodziec do zmiany.\nW jaki sposób mogę zacząć? ** ** Ja piszę tego maila, aby zacząć. W międzyczasie robię też kilka innych, mniejszych rzeczy.\nTo na czym ja się długo łapałem, to odwlekanie rzeczy, które przez to, że nie były wystarczająco duże i doskonałe, nigdy się nie wydarzyły.\nMałe kroki - truizm, banały, ale działa. Zerwij ten nisko wiszący owoc i ciesz się z pierwszego, nawet malutkiego sukcesu. Ja wysyłając tego maila z pewnością się nagrodzę!\nTo prawie wszystko na dzisiaj.\nJeszcze krótka informacja - jeśli szukasz inspiracji do rozwoju swojej kariery to przygotowuję o tym ciekawy materiał. Być może zrobię też o tym LIVE, ale ewentualne szczegóły wyślę oddzielnie.\n","tags":["perfekcjonizm","rozwój-osobisty"],"title":"Newsletter #57 - Tego maila miało nie być"},{"categories":["newsletter"],"date":"December 20, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/56/","section":"newsletter-archive","summary":"To ostatni newsletter w tym roku. Ja postaram się jak najmniej używać komputera, dam sobie odpocząć i zaczę po Świętach snuć plany na nadchodzący rok.\nTymczasem mam dla Ciebie podsumowanie ostatniego spotkania LIVE, gdzie poruszyłem temat uruchamiania baz danych w kontenerach. Okazuje się, że wzbudza on wciąż wiele kontrowersji.\nOto co musisz wiedzieć o uruchamianiu baz danych dla aplikacji na Kubernetes.\nTemat jest kontrowersyjny, gdyż: Boimy się o dostępność - kłopoty z bazą to kłopoty z całą aplikacją, a może i całą platformą Nie chcemy utracić danych - istnieje obawa, że one w jakiś sposób znikną jeśli to będzie uruchomione w kontenerach Istnieje niepewność do tego jak to działa - pojawia się “magiczna” warstwa abstrakcji (operatory), która robi “coś” i nie wiemy co dokładnie Nie wiemy czy nie zwiększy się ryzyko wycieku danych Według mnie warto iść bez obawy z bazami na Kubernetes w tych przypadkach: Dla środowisk nieprodukcyjnych i testowych Kiedy chcemy testować nowe funkcje, ustawienia i wersje silnika Dla środowisk lokalnych - na gołym dockerze lub na lokalnym Kubernetesie Według mnie warto rozważyć bazy nba Kubernetes: Gdy masz aplikację w chmurze, ale nie ma tam dobrej (lub w ogóle) usługi DB-as-a-Service Gdy masz aplikację poza chmurą, bo ciężko uzyskać taki sam stopień niezawodności, skalowania i łatwości utrzymania na tradycyjnych serwerach Wstrzymaj się z bazami na Kubernetes jeśli: Masz już stabilne rozwiązanie z grupą ekspertów, którzy wciąż to rozwijają, automatyzują i otaczają profesjonalną opieką Gdy masz aplikację w chmurze i masz dobry DB-as-a-Service - warto zapłacić za święty spokój Nie ma dobrego operatora dla Kubernetes - nie uruchamiaj z Helm Chartu i z pewnością NIE pisz własnych manifestów dla swojego silnika bazodanowego Więcej szczegółów w tym nagraniu, które jest dostępne na YouTube.\nWszystkiego Najlepszego i do Nowego Roku!\n","tags":["bazy-danych","kubernetes"],"title":"Newsletter #56 - Kiedy nie uruchamiać baz w kontenerach"},{"categories":["newsletter"],"date":"December 13, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/55/","section":"newsletter-archive","summary":"Jest już nagranie z warsztatu z zeszłego tygodnia i jeśli się nie zarejestrowałeś to i tak możesz je zobaczyć. Do tego wyszedł nowy Kubernetes, ale spokojnie, bo nie ma większych rewolucji. Myślę o LIVE w ten piątek i dam znać w odrębnym mailu o jego temacie oraz terminie. Jak masz propozycję to napisz do mnie tutaj lub na Discord.\nNagrania z warsztatu już opublikowane Warsztaty się odbyły i to bez większych niespodzianek. Zabrakło czasu na końcówkę, ale myślę, że dzięki instrukcjom łatwo jest już samodzielnie je ukończyć. Dzięki za przybycie, ciekawe pytania i rozmowę po na Discord! Warsztaty dostępne są tutaj - wystarczy podać adres mailowy, na który dostaniesz linka (mechanizm zaimplementowany na Ingress opisuję w tym wideo).\nCzy już jestem ekspertem? Czasem spotykam osoby, które uznają, że mogą być już ekspertami po poznaniu kawałka danego obszaru. To dość ciekawe zjawisko i może też tak miałeś lub dziwisz się skąd tyle pewności u innych. Postanowiłem nagrać wideo o tym, że to normalna ścieżka i opowiadam do tego moją historię z tym związaną.\nDwa projekty GitOps uznane za dojrzałe To był niemalże wyścić, który ostatecznie wygrał Flux, bo to ten projekt został jako pierwszy uznany za stabilny/dojrzały przez CNCF. Później dołączył Argo CD i mamy już dwa projekty do wyboru. Jeden jest bardziej złożony, a drugi prostszy. Nieważne którego użyjesz - każda droga do GitOps będzie tą dobrą. A teraz istnieje przynajmniej większe prawdopodobieństwo, że projekty nie zostaną zamknięte i pozostaniesz z rozwiązaniem bez jakiejkolwiek pomocy czy też wsparcia dla pojawiających się błędów.\nNowy Kubernetes 1.26 Ostatnia w tym roku wersja Kubernetes została niedawno wydana. Listę zmian najlepiej sprawdzić na doskonałym wpisie na blogu sysdig. Według mnie najważniejsze zmiany to:\nWprowadzenie filtrowania zapytań API za pomocą CEL - to umożliwi szybsze odrzucanie manifestów niespełniających naszych wymagań bez admission controllerów działających na webhookach (np. OPA, Kuyverno, Kubewarden itp.) Przejście do wersji stabilnej ustawiania polityki dla zaawansowanej kontroli wyboru podów za Servicem. Fajny ficzer i daje duże pole do optymalizacji dla większych środowisk. I w sumie tyle. Reszta to kosmetyka. Czyżby Kubernetes robił się już nudny stabilny?\nZakończył się re:Invent 2022 Poza tematem VPC Lattice nie znalazłem nic ciekawego. Jeśli coś pominąłem to daj znać.\n","tags":["argocd","fluxcd","gitops","kubernetes","kyverno"],"title":"Newsletter #55 - Po warsztatach i po nowym wydaniu Kubernetes"},{"categories":["pl"],"date":"December 9, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/pl/dostepne-nagrania-z-warsztatow-kubernetes/","section":"pl","summary":"Za nami kolejny warsztat online, który miałem okazję przygotować i poprowadzić. Tym razem wzięliśmy się za utworzenie:\nProdukcyjnej konfiguracji aplikacji Mechanizmu automatycznego jej skalowania Wysoko dostępnego (HA) klastra bazodanowego dla aplikacji Systemu automatycznego zbierania metryk Dedykowanego dashboardu dla aplikacji i bazy danych Zobacz kilka zrzutów z nagrania poniżej.\nNa warsztacie użyliśmy takich narzędzi technologii jak:\nSkaffold Docker Kubernetes na Minikube Kustomize Helm k9s (to głównie ja :) Prometheus Alertmanager Grafana Operator bazy danych Postgres od Crunchy Jeśli chcesz zobaczyć nagrania i przejść warsztat samodzielnie to zarejestruj się na tej stronie.\n","tags":["autoskalowanie","devops","edukacja","kubernetes","monitoring","prometheus","warsztaty"],"title":"Dostępne nagrania z warsztatów z Kubernetes"},{"categories":["newsletter"],"date":"December 6, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/54/","section":"newsletter-archive","summary":"Tak, mam dla Ciebie prezent od Mikołaja - ucieszysz się szczególnie jeśli chcesz poznać Kubernetesa od strony praktycznej. Ale po kolei, bo to nie jedyna wiadomość dzisiaj.\nDiscord już działa i będzie spotkanie na czacie głosowym Serwer Discord już działa i dołączyło już naprawdę sporo osób, które są zainteresowane profesjonalnym DevOpsem. Nie obyło się bez niespodzianek - zaproszenie, które wysłałem tydzień temu niefortunnie wygasło i Ci co się skontaktowali ze mną dostali nowe na maila. Dla pozostałych mam przygotowaną inną metodę zaproszenia - skorzystaj z tego linka i otrzymaj zaproszenie na maila. Planuję w tym tygodniu zorganizować pierwsze spotkanie na czacie głosowym, ale szczegóły już ustalimy na Discordzie.\nJak wykorzystać Ingress do zaawansowanej autoryzacji Nagrałem wideo, w którym ujawniam jak wykorzystuję Ingress do wpuszczania użytkowników do różnych zasobów. Część rzeczy, które publikuję chcę udostępniać dla subskrybentów mojego newslettera i za pomocą małej aplikacji oraz mechanizmów Kubernetesa wdrożyłem takie ciekawe rozwiązanie.\nBezpłatne warsztaty Kubernetes Przyjdź na warsztat i uruchom od zera aplikację i wykorzystaj do tego najlepsze praktyki. Dodasz do niej autoskalowanie z użyciem obiektu HorizontalPodAutoscaler (HPA), aby samodzielnie się skalowała. Aplikację podłączysz pod niezawodny klaster bazodanowy, który będzie odporny na awarie i będzie miał podłączone metryki. Wszystkie komponenty będą monitorowane przez stack monitoringu, który zainstalujesz i skonfigurujesz. Utworzysz też dashboardy do przeglądania ich stanu.\nProfesjonalnie i praktycznie – bez ściemy i nudy! Warsztat odbędzie się 8 grudnia (czwartek) o 19:00. Szczegóły i zapisy na /warsztaty-kubernetes-2022/.\n","tags":["hpa","kubernetes","warsztaty"],"title":"Newsletter #54 - Mikołaj zaprasza na bezpłatny warsztat"},{"categories":["newsletter"],"date":"November 29, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/53/","section":"newsletter-archive","summary":"Decyzja zapadła i głosem większości wygrał Discord jako platforma dla społeczności profesjonalistów DevOps w Polsce. Bardzo się cieszę, że od teraz istnieje takie miejsce, gdzie będę mógł porozmawiać z osobami zajmującymi się tą najciekawszą działką IT. Szczegóły poniżej, a dalej znajdziesz kolejną część moich obserwacji dotyczących losu Kubernetes.\nOdpalam serwer Discord dla profesjonalistów DevOps! Ankieta z ostatniego tygodnia wyłoniła zwycięzcę - wybraliście Discord jako miejsce spotkań i wymiany doświadczeń. Będę tam bywał w miarę regularnie i chcę, aby to było miejsce dla profesjonalistów DevOps i ludzi, którzy chcą się w tym kierunku rozwijać. Tak, wiem, że jest już wiele innych kanałów i grup. Mało jest jednak miejsc, które nie ograniczają się do poszczególnych chmur, a są dedykowane wykorzystywaniu najlepszych praktyk. Jeśli jesteś w branży lub zaczynasz tą fascynującą przygodę to chyba nie będzie lepszego miejsca, aby spotkać innych pasjonatów automatyzacji, Infrastructure-as-Code, Kubernetes, Terraform i innych technologii wspierających mądre lenistwo. To będzie też miejsce przyjazne wszystkim fanom sernika - niezależnie od tego czy z rodzynkami czy bez ;)\nZ przyjemnością zatem oficjalnie otwieram serwer cloudowski na Discord i już teraz zapraszam Cię do rejestracji! /discord\nDokąd zmierza Kubernetes - część 2 Tydzień temu zacząłem pisać o moich obserwacjach dotyczących drogi jaką zmierza Kubernetes i cały ekosystem wokół. Dzisiaj drugia i ostatnia część tych przemyśleń na podstawie konferencji KubeCon North America 2022.\nWASM jako kolejny krok ewolucji Wygląda na to, że WASM będzie technologią, która popchnie kontenery w jeszcze bardziej wyspecjalizowane i zamknięte oprogramowanie orkiestrowane między innymi na Kubernetes. To dla pewnych aplikacji wyeliminuje konieczność używania silnika do uruchamiania tradycyjnych kontenerów i zastąpi je środowiskiem uruchomieniowym WebAssemly. Nawet Dockera już zaczyna wspierać uruchamianie takich aplikacji. Nie przewiduję, aby pisanie Dockerfile już nie było potrzebne, ale dla wyspecjalizowanych aplikacji będzie to szybsze i bezpieczniejsze.\nCzas na zabezpieczenie łańcucha dostaw oprogramowania Widać rosnący trend ku zabezpieczaniu łańcucha dostaw. Bardzo głośny atak na SolarWinds pokazuje, że to jest olbrzymmi obszar mogący prowadzić to naprawdę skutecznych ataków - niezależnie od tego jak bardzo zabezpieczone jest samo środowisko produkcyjne. Z pewnością GitOps jest dobrym początkiem i już tutaj można zadbać o bezpieczne aplikowanie zmian. Do tego potrzebne jest zaimplementowanie podpisywania zmian w repozytoriach oraz podpisywanie obrazów.\nBezpieczeństwo platform to wciąż priorytetowy temat Zabezpieczenie środowisk opartych o kontenery będzie poruszane na każdej konferencji i można to zauważyć po ilości prezentacji, ale również po ilości projektów, które adresują te wyzwania. To świadczy o adopcji Kubernetes na środowiskach produkcyjnych i obawach z tym związanych. Ciekawym projektem jest zestaw najczęstszych błędów bezpieczeństwa - OWASP dla Kubernetes . Kiedyś projekt OWASP adresował wyzwania aplikacji webowych, a teraz wskazuje na top 10 wyzwań dla organizacji używających Kubernetesa.\nNatrafiłem też na ciekawą prezentację Cilium omawiającą NetworkPolicy. Bez tego też nie wyobrażam sobie środowiska produkcyjnego, a to co pokazuje ich CNI to naprawdę majstersztyk. Dla tych co chcą widzieć co się dzieje dokładnie na aplikacjach uruchomionych na klastrze będę zawsze polecał projekt Falco. Ta prezentacja fajnie pokazuje go w działaniu. Konfiguracja może i nie jest trywialna, ale otwiera tyle możliwości o jakich do tej pory mogliśmy tylko pomarzyć - to wszystko oczywiście dzięki eBPF.\nKubernetes jest do budowania platform I na końcu ważne spostrzeżenie - klaruje się cel do jakiego Kubernetes będzie używany. Na samym końcu będzie on podstawą do Internal Developer Platform ( IDP ). To zaczyna się rozkręcać i to fajne intro pokazuje jak może to zmienić pracę w organizacji. Ta prezentacja z kolei pokazuje, że może to być wspaniały początek większych zmian architektonicznych - taki katalizator digital transformation.\nTo ma dla mnie absolutnie sens. Kubernetes od dawna nie jest tylko orkiestratorem - to doskonała platforma z rozszerzalnym API, z wieloma projektami wokoło (bezpieczeństwo, skalowanie, przenaszalność, hybrydowość itp.), zaangażowanym community i wsparciem największych firm oraz szeroką adopcją. W niedługim czasie będzie coraz więcej przykładów jak Kubernetes nie tyle pozwala uruchamiać kontenery co jeszcze zmienia sposób pracy organizacji. Do tego potrzebne będzie inne spojrzenie i zbudowanie platformy - niezależnie czy na cloud, on-prem czy w hybrydowym trybie.\n","tags":["devsecops","gitops","idp","kubernetes","security","wasm"],"title":"Newsletter #53 - Uruchamiam społeczność profesjonalistów DevOps"},{"categories":["newsletter"],"date":"November 22, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/52/","section":"newsletter-archive","summary":"Już minęło trochę czasu od konferencji KubeCon i w końcu udało mi się zebrać najnowsze trendy z ekosystemu Kubernetes. Zatem dzisiaj dla odmiany bardzo technicznie. To pierwsza z dwóch części - za tydzień prześlę drugą.\nQuo vadis Kubernetes Poniżej najważniejsze rzeczy jakie udało mi się wyłapać z prezentacji z ostatniego KubeCon North America 2022. W większości dodałem też linki do najciekawszych wideo.\nWszędzie GitOps Nie ma odwrotu - zarządzanie z kodu w stylu GitOps staje (stało?) się standardem.I to dotyczy nie tylko Kubernetes, ale również Terraform. Mi od zawsze podobała się koncepcja środowisk poglądowych (preview environments) i z GitOps mają one jeszcze świetlaną przyszłość. Okazuje się, że wciąż jest to najłatwiejszy sposób na testowanie w niektórych przypadkach.\neBPF rządzi Ogólnie widać trend, gdzie coraz więcej narzędzi będzie tworzonych na podstawie eBPF. Są ta między innymi:\npluginy CNI (oczywiście Cilium, ale też Calico) do lepszego zarządzania ruchem sieciowym narzędzia do audytu (np. Falco) platformy do diagnozowania i profilowania (np. Pixie) Service Mesh ( Cilium Service Mesh) To naprawdę otwiera ekscytujący rozdział wykiorzystania linuksa do zarządzania ruchem sieciowym, zwiększenia bezpieczeństwa i widoczności! Jeśli nie wiesz czym jest eBPF to zobacz to doskonałe wprowadzenie.\nNadchodzi lepszy Ingress, czyli Gateway API Mamy sporo już implementacji Ingress, ale to wciąż ubogi interfejs. Stąd wkrótce będzie widać częściej adopcję modelu Gateway API, który jest bardziej elastyczny i dopasowany do różnych potrzeb. To jeszcze chwila pewnie, ale już warto poznać jaka będzie przyszłość zarządzania ruchem do aplikacji webowych.\nNiewiele słychać o operatorach i Helm Możliwe, że Helm już dojrzał i jest po prostu jednym z narzędzi, których używają wszyscy korzystający z Kubernetesa. Mi nadal nie podoba się, że na ArtifactHub jest ponad 9 tysięcy chartów i ciężko znaleźć te o dobrej jakości. Ale tak wygląda świat open source - każdy może publikować i “publiczność” decyduje o popularności.\nNiewiele też słychać o operatorach i tak jak podejrzewałem mogą one stać się niszowe. Będą wykorzystywane jedynie dla małej, wyspecjalizowanej części oprogramowania uruchamianego na Kubernetes. Niby Operator SDK ułatwia ich pisanie, ale chyba jedynie Red Hat ze swoim OpenShift wykorzystuje go w pełni (mają tam dziesiątki operatorów, łącznie z takim kontrolującym wygląd konsoli po Custom Resource!).\n","tags":["cilium","ebpf","gitops","kubernetes"],"title":"Newsletter #52 - Dokąd zmierza Kubernetes"},{"categories":["newsletter"],"date":"November 8, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/50/","section":"newsletter-archive","summary":"Rzadko piszę o Microsoft, a w końcu to olbrzymi gracz na rynku cloudowym (podobno drugi, tuż za AWS). Tak się składa, że ostatnio wypuścili garść ciekawych nowości dla swojego Kubernetesa, czyli AKS. To cieszy, bo oznacza, że Ci którzy korzystają z chmury Microsoftu nie zostaną w tyle za EKS czy moim ulubionym GKE. Wiem, że Azure jest w sporej ilości firm w Polsce - widzę to szczególnie podczas szkoleń. A dla tych co nie mają Azure przygotowałem też garść innych nowości. Zapraszam!\nNowe Kyverno weryfikuje podpisy manifestów Kyverno to natywne rozwiązanie do aplikowania reguł bezpieczeństwa na klastrach Kubernetesowych. Jest to świetna alternatywa dla OPA Gateway i prostsza w użyciu. Niedawno wyszła wersja 1.8, która przynosi kilka zmian. Umożliwia sprawdzanie reguł nowego standardu bezpieczeństwa, czyli PodSecurity. Ciekawą nową funkcją jest też weryfikacja manifestów. Wszystko wskazuje, że idziemy w stronę podpisywania wszystkiego - od commitów git, przez obrazy kontenerów aż po manifesty. Wygląda to ciekawie, a Kyverno jest moim faworytem. Polecam szczególnie tym, którzy nie “polubili” się z językiem rego wykorzystywanym w OPA.\nFilm o prometheus Obok wydanego dokumentu o Kubernetes (część 1 i 2) doszedł jeszcze jeden - tym razem o projekcie Prometheus. Przyznam się, że jeszcze nie obejrzałem, ale zamierzam. Znam tylko pobieżnie historię powstania i sam jestem ciekaw jak tak świeży (biorąc pod uwagę inne projekty open source) projekt zdominował tak ważną działkę IT jaką jest monitoring i stał się niedzownym elementem środowisk skonteneryzowanych.\nRed Hat umożliwia szybsze testowanie OKD Ogłoszono wydanie OKD Streams. To rozwiązanie pozwoli wszystkim odważnym na testowanie nowych funkcjonalności zanim trafią one do wersji stabilnej. To zgodne z przeznaczeniem OKD, bo to ma być wersja community flagowego produktu Red Hata - OpenShift Container Platform. Podobno w CERN używają tego produkcyjnie, ale ja słyszałem o wielu problemach tego projektu (szczególnie po perturbacjach związanych z wersją 4). Jeśli używasz tego u siebie to chętnie się dowiem czy OKD osiągnęło już stabilność i można to polecać dla środowisk on-prem obok EKS Anywhere czy VMware Tanzu Community Edition.\nAlternatywa dla Helm i Kustomize jest już stablina Mowa oczywiście o CDK8S+. Jeśli zatem zamiast pisać yamle czy szablony dla chartów, to już śmiało możesz użyć swojego ulubionego języka i tam opisywać stan platformy. Oczywiście jeśli zechcesz to spiąć z rozwiązaniem GitOps to póki co będziesz musiał do Gita zapisywać wygenerowane manifesty. Ale dla niektórych ucieczka od długich yamli jest tego warta i doskonale to rozumiem.\nNowości w AKS I temat główny, czyli garść nowości w Azure Kubernetes Service.\nPierwsza to wsparcie dla IPVS. Od teraz można testować na AKS wewnętrzny load balancing, który nie jest oparty o reguły iptables (pokazuję jak to działa w moim wideo), a o kernelowy moduł IPVS. Dlaczego chcesz IPVS? Bo możesz użyć innych algorytmów balansowania ruchem i do tego lepiej on działa dla środowisk o większej ilości podów.\nKolejna nowość to wsparcie CNI opartego na Cilium. A jak masz już Cilium to możesz między innymi użyć ich zaawansowanego firewalla działającego na warstwie L7. Do tego szyfrowanie, tracing i wszystkie inne bajery, które mamy dzięki ePBF.\nAKS może też działać na dystrybucji Mariner, którą Microsoft utworzył dla rozwiązań działających na kontenerach. Nie znam za dużo szczegółów, ale wygląda mi to na podobny projekt do CoreOS czy też googlowego COS. W końcu skoro wszystko jest i tak w kontenerach to można uprościć działanie hosta, którego główne zadanie to dostarczanie cpu, pamięci i kernela do obsługi kontenerów.\nI na koniec AKS udostępnia wertykalny autoscaler, czyli VPA. Sam nie korzystam, bo nie znalazłem póki co zastosowania. Zakładam jednak, że znajdą się tacy, których Microsoft tym uszczęśliwi.\nWażne, że nowe funkcje są dodawane i wszystko idzie do przodu jak powinno.\n","tags":["aks","kubernetes","kyverno","okd","openshift"],"title":"Newsletter #50 - Interesujące nowości dla Kubernetes od Microsoft"},{"categories":["newsletter"],"date":"November 1, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/49/","section":"newsletter-archive","summary":"W zeszłym tygodniu zakończył się KubeCon 2022 North America. Ja jeszcze zbieram najciekawsze materiały i nowości tam ogłoszone - jak będą gotowe to nie omieszkam się z nimi podzielić tutaj. Ale jest też dość ważna informacja, która gruchnęła w zeszłym tygodniu. Otóż AWS ogłosił powstanie lokalnej strefy (Local Zone) w Warszawie.\nCzy to oznacza, że mamy dostępny region AWS w Polsce? No niestety nie. To czym jest ta strefa i co możemy z nią zrobić? Otóż zgodnie z opisem mamy do dyspozycji tylko następujące usługi:\nVPC EKS - Kubernetes jako usługa EC2 I tyle. Jak widać wystarczy, żeby zbudować jakieś małe rozwiązanie. W końcu mamy najważniejszy element czyli… EKS? No dobra - z VPC i EC2 da się zrobić naprawdę sporo. Jest tylko kilka ograniczeń.\nPo pierwsze mamy do dyspozycji tylko jeden storage - gp2. Pewnie większości wystarczy. Po drugie to jest to tylko jedna strefa i jeśli planujesz zbudować rozwiązanie zgodne z zasadą Design for Failure to może być ciężej. Lokalna strefa w Warszawie jest podpięta pod region we Frankfurcie i tylko tak możesz jej użyć. Po trzecie są tylko “pełnoprawne” instancje (c5, r5, m5 i G4dn) - nie ma tych tańszych, które tak lubimy. Instancje t3 będą kiedyś, a zatem nasze cebulowe dusze muszą się uzbroić w cierpliwość.\nJak użyć nowej lokalnej strefy? To dość proste. Oto niezbędne kroki.\nWybierz z konsoli AWS region Frankfurt (eu-central-1) Otwórz konfigurację usługi EC2 i włącz strefę eu-central-1-waw-1 Otwórz konfigurację VPC i utwórz nową podsieć (Subnet) wykorzystując tą nową strefę Od teraz możesz tworzyć wspierane instancje i węzły dla EKS.\nA czy są jakieś alternatywy? Owszem, ale szału nie ma. Google ma pełnoprawny region w Warszawie już od prawie 1.5 roku. Jest dostępny najlepszy Kubernetes (GKE) i są też tanie vmki. Może nie ma wszystkich dostępnych usług, ale ma zdecydowaną większość i ma aż trzy niezależne strefy dostępności.\nA co z wielką 1-miliardową inwestycją ogłoszoną ponad 2 lata temu? Póki co regionu nie mamy. Możliwe, że jakieś prace trwają, ale na razie jest cisza. A jeśli nie chcesz lub nie musisz używać dużych dostawców to możesz się skusić na mniejszego jakim jest francuski Scaleway. Od 2 lat ma on swój region, gdzie odpalisz maszyny wirtualne i Kubernetesa jako usługę.\n","tags":["aws","azure","cloud"],"title":"Newsletter #49 - Polska chmura rośnie"},{"categories":["newsletter"],"date":"October 25, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/48/","section":"newsletter-archive","summary":"Może nigdy to za mocne słowo, ale podjąłem decyzję o zaprzestaniu pisania e-booków. Przynajmniej tych w formie produktu. Kilka ostatnich tygodni sporo myślałem, myślałem aż wymyśliłem. Konsekwencją tego są dwie rzeczy, które opisuję poniżej.\nCzego się nauczyłem sprzedając mój e-book “Stocznia Kubernetes” Ten hashtag #ZawszeDoPrzodu to nie są puste słowa. Ja naprawdę chcę się uczyć na wszystkim co robię. W wakacje wydałem e-booka “Stocznia Kubernetes” i podczas tego całego procesu sporo się dowiedziałem o sprzedaży, ale przede wszystkim o tym co działa, a co nie. Spisałem moje przemyślenia w formie artykułu i jeśli jesteś zainteresowany to zapraszam do przeczytania. Dowiesz się dlaczego nie zostanę TikTokerem i co robiłem, aby próbować przekonać Was do zakupu i co z tego wyniosłem.\nTL;DR; E-booki to nie jest dobry format i od teraz będę wydawał głównie kursy wideo.\nNie ma już e-booka, ale jest kurs “Stocznia Kubernetes” to już nie jest e-book, ale kurs wideo. Włożyłem naprawdę w niego sporo pracy i z kilkudziesięciu stron e-booka wyszło mi ponad 2 godziny nagrań wideo. To jest naprawdę rozbudowany materiał o budowaniu potoków i zaawansowanych wdrożeniach. Wydaje się, że jest to pierwszy tego typu kurs w Polsce, a dla mnie to dopiero początek. Ci co kupili wersję e-book dostali darmowy upgrade do formatu kursu (jeśli kupiłeś, a nie dostałeś maila z dostępem to daj znać).\nWkrótce zrobię promocję otwierającą. Informację wyślę do tych, którzy się zapisali w wakacje na szkolenie “5 sekretów budowania potoków CI/CD”. Na stronie kursu możesz się też zapisać na listę jeśli jesteś również zainteresowany. Promocję otworzę w okolicach moich urodzin, a te już wkrótce :)\n","tags":["ebook","edukacja","kubernetes","kurs"],"title":"Newsletter #48 - Nigdy więcej"},{"categories":["pl"],"date":"October 18, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/pl/czego-sie-nauczylem-sprzedajac-e-book-stocznia-kubernetes/","section":"pl","summary":"Mam już to za sobą, ale nie było łatwo. Zakończyłem sprzedaż mojego e-booka \u0026ldquo;Stocznia Kubernetes\u0026rdquo;. Przeczytałem gdzieś, że dopóki nie sprzedaż swojego pierwszego produktu to tak naprawdę nie dowiesz się najważniejszych rzeczy. To taki chrzest bojowy.\nPomimo przeczytania wielu publikacji, określenia grupy docelowej, zainwestowania czasu w przygotowania, to dopiero sprzedaż pozwala na sprawdzenie założeń w praktyce.\nDo tej pory publikowałem głównie darmowe treści - od moich darmowych e-booków, newslettera, przez podcast, artykuły i nagrania wideo.\nNa początku roku podjąłem jednak decyzję, że chcę w całości zająć się rozwojem kompetencji DevOps w Polsce. A nie da się tego robić bez sprzedaży - inaczej byłoby to po prostu hobby obok mojej zwykłej pracy.\nZdecydowałem zatem, że napiszę e-booka i zacznę go sprzedawać.\nDlaczego e-book Chciałem dostarczyć dużo wartościowej wiedzy, która jest łatwo aplikowana. Już tak mam, że nie lubię skupiać się tylko na teorii. Jest takie powiedzenie, które mi przyświeca:\n\u0026ldquo;Ideas are cheap, execution is everything\u0026rdquo;\nSlajdów i prezentacji jest mnóstwo, ale jak z nich zbudować rozwiązania, które przynosi wymierne korzyści to już inna bajka. Poza tym napisałem już wcześniej dwa takie e-booki z tą tylko różnicą, że były one za darmo. Niby drobna różnica, ale jak się okazuje to co jest za darmo niekoniecznie musi sprawdzać się jako produkt.\nDlaczego znowu temat Kubernetesa Fakt, to już może być nudne. Ile można tłuc o tej jednej technologii? Całkiem długo jak widać i to nie bez przyczyny.\nSam Kubernetes jest już naprawdę powszechnie używany i zgodnie z raportem State of DevOps 2022 ponad 50% aplikacji jest dostarczanych w kontenerach.\nTo nie jest jedna z tych technologii, które dorzucają tylko drobną zmianę. To jest coś co zmieniło drastycznie podejście do tego jak wdrażane są aplikacje. Stąd prowadząc szkolenia o Kubernetes od 2016 roku i aplikując go praktycznie w wielu projektach, postanowiłem, że tym razem również wydam coś opartego o ten wspaniały soft.\nPostanowiłem też, że będzie to materiał nie dla początkujących a dla ciut bardziej zaawansowanych. Materiałów dla tych pierwszych jest dużo, a już o bardziej złożone tematy trudniej. I decyzja ta była poprzedzona ankietą wśród moich sybskrybentów, z której wprost wynikało, że jest to gorący temat. Gdybym ich nie zapytał, to temat byłby z goła inny.\nI tak powstał e-book \u0026ldquo;Stocznia Kubernetes\u0026rdquo;.\nKampania reklamowa Po dość jednak długim okresie pisania e-booka, tworzenia atrakcyjnej szaty graficznej (tak, mam tu jakiegoś bzika na tym punkcie - szczególnie, że otrzymane grafiki mnie oczarowują) czas przyszedł na kampanię reklamową. Chciałem dotrzeć do jak największej ilości osób, które miały już okazję pracy z Kubernetesem, a jednocześnie potrzebowały praktycznych informacji o automatycznych wdrożeniach, zaawansowanych technikach deploymentu i jak to połączyć z podejściem GitOps.\nI tak zacząłem przygotowania do kampanii. Wziąłem się do tego naprawdę poważnie. W trakcie przygotowań powstało 5 krótkich filmów i 5 zestaw grafik, które następnie miały zostać umieszczone na moich kanałach mediów społecznościowych.\nPoszło na to sporo czasu i wysiłków, a do tego zatrudniłem profesjonalną firmę do prowadzenia mojej kampanii. Po prostu nigdy tego nie robiłem i wolałem upewnić się, że będzie to zrobione dobrze, a ja będę mógł się skupić n tym co znam i potrafię.\nW trakcie kampanii były użyte moje kanały Facebook, Instagram i TikTok. Oczywiście dotyczy to reklam płatnych, bo sam również rozpocząłem kampanię mailową. A jakie były efekty? O tym przeczytasz dalej.\nMoja pierwsza taka sprzedaż Cała kampania była zwieńczona webinarem, a tak naprawdę szkoleniem na żywo, gdzie prezentowałem najciekawsze elementy z mojego e-booka.\nTo nie było moje pierwsze wystąpienia live i czuję się swobodnie opowiadając o technologii. Było to jednak pierwsze wystąpienia, w ramach którego miałem zachęcić do kupna mojego produktu. I nie było to dla mnie łatwe.\nMoże to perfekcjonizm, który z tyłu głowy tworzył myśli o tym, że to nie jest produkt wystarczająco dobry. Może to efekt nowicjusza, który zanika razem z praktyką. Z pewnością nie czułem się jak ryba w wodzie. I z tego co usłyszałem od zaufanej osoby, było to widać/słychać.\nJa i tak jestem z tego zadowolony. To jest olbrzymi skok dla mnie. Aby dojść do tego etapu musiałem ułożyć sobie w głowie ważną dla mnie rzecz.\nZacząłem wierzyć, że to co oferuję przynosi prawdziwą wartość dla moich odbiorców i to w mojej kwestii jest przekonanie ich o tym. Bez tego czułbym się jak oszust sprzedający bezużyteczne gadżety (czy tylko do mnie wciąż dzwonią sprzedawcy marzeń oferując prezentację garnków?).\nSkoro wierzę, że potrafię dostarczyć produkt, który może pomóc w rozwoju kariery, to moim obowiązkiem jest jego jak najlepsze zaprezentowanie. To było i jest dla mnie kluczowe.\nInformacje zwrotne Nie będę tu omawiał wyników sprzedaży, a czego się nauczyłem. Po kampanii i pierwszych sprzedanych e-bookach, poprosiłem o opinię osoby, które go kupiły oraz te, które się nie zdecydowały.\nTo jest kluczowe - bazować na faktach, a nie domysłach. Obok liczb i statystyk dostępnych z różnych narzędzi, dostałem kilka bardzo cennych informacji od moich klientów i osób zainteresowanych tematyką.\nCzy wszystkie opinie były miłe i pozytywne? Oczywiście, że nie! Część była ciężka, ale pozwoliła mi nauczyć się czegoś cennego. Znowu przypomina mi się cytat (wersja cenzuralna):\n\u0026ldquo;Prawda cię wyzwoli, ale najpierw mocno wkurzy\u0026rdquo;\nPrzełknięcie niewygodnych faktów jest nieprzyjemne, ale czasem to jedyna metoda, aby rosnąć dalej. Tak było tym razem u mnie i pozwoliło mi podjąć dalsze decyzje.\nA czego się konkretnie nauczyłem?\nCenne lekcje Oto zatem lista rzeczy, których się nauczyłem na mojej pierwszej sprzedaży:\n1. E-booki nie są dobrym formatem na sprzedaż Pomimo, że e-booki sprawdzają się wspaniale jako darmowe treści, to moi odbiorcy nie za bardzo widzą to jako format, za którego chcą zapłacić.\nMiałem te liczby w moich ankietach przed rozpoczęciem prac, a jednak postanowiłem pójść tą drogą. Dodatkowo natrafiłem w międzyczasie na wynik ankiet od HackerRank, które jasno pokazywały, że większość developerów woli kursy wideo. Koniec, kropka.\nTen trend jest widoczny im młodsi są odbiorcy. I nie twierdzę, żer czytanie zaniknie, ale skoro łatwiej jest zdobywać umiejętności z wideo to dlaczego miałbym na siłę oferować tekst? Szczególnie, że sam jestem wzrokowcem i sam dostrzegam, że tego typu treści są łatwiej dla mnie przyswajalne.\nEksperyment zamykam z tworzeniem produktów innych niż wideo. Od teraz będę tworzył prawie tylko i wyłącznie treści oparte o wideo.\n2. W e-bookach ciężko zawrzeć praktyczną wiedzę techniczną Tak, są książki techniczne. Tak, sam nawet je czytam/czytałem. Ale jeśli chcesz wyjść poza koncept teoretyczny to pokazywanie kodu i komend jest naprawdę trudne.\nWchodzą tu tematy związane z formatowaniem, opisywaniem tego co powinno być efektem, umieszczaniem diagramów i obrazków. Nawet jak traktujesz to profesjonalnie i wytaczasz narzędzia typu Asciidoctor (bo w końcu \u0026ldquo;wszystko w kodzie\u0026rdquo;), to i tak jest ciężko to sformatować, aby było czytelne i atrakcyjne dla odbiorcy.\nOstatecznie zawsze możesz to umieścić na stronie, ale to już nie to samo. To również kwestia percepcji - znowu przyzwyczailiśmy się, że strony czytamy prawie zawsze za darmo. Sproduktyzowanie tego jest po prostu ciężkie. Technicznie możliwe, ale tu nie o technologię chodzi.\n3. Zamiast reklam lepiej skup się na treściach Moja grupa docelowa liczy kilkadziesiąt tysięcy osób, bo na tyle szacuję liczebność ludzi zajmujących się DevOps w Polsce. Pewnie dużej części wyświetliły się moje reklamy, ale z jakiejś przyczyny (np. jestem zbyt brzydki itp.) nie powodowały one większego zainteresowania.\nI tak jak pisałem wcześniej - to nie była kwestia złego użycia narzędzi, bo tu oddałem sprawę ekspertom. Po prostu najwidoczniej moja grupa jest odporna na reklamy. W sumie się nie dziwię - sam nie posiadam telewizji, reklamy mnie męczą i staram się je omijać.\nZa to mogę polegać na osobach, do których już dotarłem i które miały już kontakt ze mną lub z moimi treściami. One stanowiły znakomitą większość osób zapisanych na darmowe szkolenie, a ci którzy mi zaufali kupując e-booka również w ponad 70% byli już wcześniej subskrybentami mojego newslettera.\nReklamy działają, ale nie na taką skalę jak treści. I dlatego na nich będę dalej opierał moją działalność.\n4. Nie zaczynaj kampanii w wakacje Tak się złożyło, że zdecydowałem się na sprzedaż w wakacje. Frekwencja na szkoleniu dopisała, liczba zapisanych również, ale dostawałem informacje, że ktoś czeka na zatwierdzenie zakupu od osoby będącej na urlopie.\nPoza tym sam rozumiem, że gdy pogoda sprzyja to siedzenie przed ekranem i skupianie się na technologii może być trudne. Stąd wakacje zostawię na odpoczynek lub pracę \u0026ldquo;od zaplecza\u0026rdquo;.\n5. TikTok nie jest dobry na reklamy (przynajmniej w Polsce) Tak, mam konto na TikTok - login cloudowski jak na pozostałych. Ale nie tańczę, nie zmieniam siebie pod to medium społecznościowe. Testowałem je w ramach sprawdzenia czy uda mi się znaleźć tam moich odbiorców.\nNagrywałem krótkie wideo z treściami dotyczącymi technologii i praktyk DevOps. O dziwo zyskałem kilkuset followersów, ale jak przyszło do zaproszenia na darmowe szkolenie (ze sprzedaży tam zrezygnowałem) to konwersja była symboliczna.\nTe same płatne reklamy na Facebook czy Instagram były 10-krotnie bardziej skuteczne. Te na TikTok docierały do wielu ludzi z mojej grupy docelowej, ale niewiele było zainteresowanych już czymś bardziej konkretnym.\nNo i nie mogę nie wspomnieć o tym jak żenujący jest poziom wsparcia na TikTok. Do tej pory nie odzyskałem pieniędzy po zatrzymaniu reklamy, a support wydaje się być chyba botem, go dostaję te same głupie odpowiedzi.\nTakże chyba TikTokerem nie zostanę. Może i to prężnie rozwijające się medium, ale w zakresie docierania do grupy docelowej (np. kiepskie statystyki, brak supportu) z treściami technicznymi nie dorasta do pięt Google czy nawet Meta.\n6. Przygotowanie treści wideo jest kilkukrotnie bardziej złożone Wpis ten publikuję po nakręceniu pierwszego mojego kursu wideo. Różnice są dość znaczne jeśli chodzi o poziom złożenia. Nawet jak mam już treść to nagrywanie trwa bardzo długo.\nMusisz przygotować miejsce, mieć dobre oświetlenie, względnie mały hałas (na szczęście mikrofon dynamiczny niweluje większość) no i sensownie to nakręcić. Poprawki w e-booku to kwestia minut. Niektóre ujęcia z kolei mogą być kręcone wielokrotnie. A nawet jak nakręcisz to i tak czeka Cię długi montaż (ja jeszcze go nie zlecam, ale po tym już chyba zacznę).\nA do tego nagrania demo. Do tej pory moje wideo nagrywałem bez większego przygotowania, ale ze względu na to, że szanuję czas moich klientów, to nawet złożone sesje techniczne w kursie robię treściwie. Mają zawierać esencję i nie straszyć długością. A to wymaga jeszcze więcej powtórek, rozwiązywania pojawiających się znienacka problemów i anielskiej cierpliwości.\nAle za to satysfakcja jest ogromna. Widząc końcowy efekt wiem, że się opłacało poświęcać tyle czasu. Myślę, że moi klienci też będą zadowoleni.\n7. Zainteresowanie tematyką DevOps w Polsce jest, ale\u0026hellip; Tu jest dla mnie najcenniejsza lekcja, ale wciąż pozostawia wiele niewiadomych.\nTak jak pisałem wcześniej - w Polsce jest kilkadziesiąt tysięcy ludzi zajmujących się lub zainteresowanych obszarem DevOps. Biorąc pod uwagę, że tylko część zainteresowana jest samodzielnym rozwojem, to nie jest to olbrzymia grupa.\nObecnie wciąż testuję czy uda mi się dotrzeć do odpowiednio dużej jej części, abym mógł skupić się tylko na tworzeniu wysokiej jakości treści pomagających w rozwoju karier DevOps.\nBo zainteresowanie jest, ale wciąż nie wiem czy rynek pozwoli mi na tym przetrwać. Jeśli nie to będę musiał szukać innych sposobów na rozwój mojej działalności lub wrócić do zwykłej pracy (czego bardzo, bardzo nie chcę). Czas pokaże, a ja dołożę wszelkich starań.\n8. Czas na treściwe kursy wideo Ostatnia lekcja to postanowienie - od teraz moje produkty to kursy wideo. Możliwe, że to \u0026ldquo;potknięcie\u0026rdquo; z wydaniem e-booka było mi potrzebne, aby przykuć moje skupienie właśnie na tym obszarze.\nW mojej głowie jest wciąż dużo pomysłów (a część nawet spisana) na kolejne kursy. Nie wszystkie o Kubernetes, ale wszystkie z konkretną dawką wiedzy o najważniejszych technologiach.\nLiczę, że uda mi się w ten sposób rozwinąć działkę DevOps w Polsce i pomóc w rozwoju karier. W końcu to tylko technologia, a ja pokażę jak w odpowiedni sposób da się ją prosto poznać.\n","tags":["biznes","devops","ebook","edukacja","kubernetes","rozwój-osobisty"],"title":"Czego się nauczyłem sprzedając mój e-book \"Stocznia Kubernetes\""},{"categories":["newsletter"],"date":"October 18, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/47/","section":"newsletter-archive","summary":"Mógłbym Ci napisać o tym jak podcast Kubernetes traci swojego prowadzącego, o nowej wersji 1.12 Vaulta, czy też o tym jak użyć Kubescape w potokach CI/CD.\nAle zamiast tego napiszę o czymś innym. To nie jest w żaden sposób treść “coachingowa”. Tak jak DevOps to nie tylko technologia, ale też to nie tylko kultura.\nDzisiaj podzielę się z Tobą krótkimi spostrzeżeniami. Przebywając od 2 tygodni poza domem na tzw. “workation”, staram się pracować i szukać nowych pomysłów.\nTo co sobie uświadomiłem lub też przypomniałem w tym czasie to kilka rzeczy, które mogą się przydać i Tobie:\nKonsekwentne działanie to piękna rzecz, ale wciąż bardzo ciężka w utrzymaniu.\nTo 47 newsletter wysyłany przeze mnie (prawie) co tydzień i jest on dla mnie olbrzymią motywacją do działania. Szczególnie wtedy, gdy dostaję maile od Was. Zmiana środowiska pomaga uporządkować myśli i nabrać nowej perspektywy\nStare schematy lubią się uaktywniać w znajomym środowisku. Nie trzeba wyjeżdżać daleko i dlatego osobiście skorzystam z dobrodziejstw parków warszawskich po powrocie - to działa! Robienie wszystkiego samodzielnie naprawdę nie ma sensu\nZdecydowanie lepiej zapłacić za usługę lub znaleźć kogoś kto zrobi to za Ciebie. Ja za dużo czasu spędziłem budując (lub próbując budować) coś samodzielnie. I jasne - może to nie będzie w 100% to co sobie wymarzyłeś, ale odzyskasz mnóstwo czasu. Na końcu to czas się liczy najbardziej. Skupienie przynosi efekty\nTrochę żałuję, że nie było mnie na ostatnich konferencjach na żywo takich jak DevOps Enterprise Forum czy nadchodzącym DevOps Days w Warszawie, ale to nie pozwoliłoby mi utrzymać skupienia na tym co robię. Bo udało mi się dokończyć pewien projekt, który jest dla mnie bardzo, ale to bardzo ważny.\nCzasem są to trudne decyzje, ale rozpraszanie energii powoduje dalsze opóźnienia, a ja chcę dostarczać jeszcze lepszych treści dla moich odbiorców. W przyszłym tygodniu wyślę więcej szczegółów dotyczących efektów tej pracy. Nie ma tak po co pędzić\nW kraju, gdzie obecnie przebywam jest nagminny zwyczaj przechodzenia na czerwonym świetle, a jeśli nie będziesz wystarczająco szybki i spostrzegawczy na skrzyżowaniu (gdzie nie ma pasów!) to skończysz z zarysowanym autem lub zostaniesz upomniany klaksonem.\nJednocześnie ludzie nigdzie nie pędzą, siedzą wieczorami w knajpkach, piją rano kawkę w kafejkach i czuć chillout. Taki klimat powoduje, że też zaczynasz myśleć o tym, aby się nie spieszyć. Też zaczynasz pić pomału kawkę rano i odchodzisz od ekranu po południu, aby skorzystać z uroków słońca. Ja się zatrzymuję, przynajmniej na chwilę. Za tydzień wracam z kolejnym newsletterem i podzielę się z Tobą czymś ważnym.\n","tags":["perfekcjonizm","rozwój","rozwój-osobisty"],"title":"Newsletter #47 - Zatrzymaj się"},{"categories":["newsletter"],"date":"October 11, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/46/","section":"newsletter-archive","summary":"Wyszedł nowy raport State of DevOps 2022 i temu w całości poświęcam ten newsletter.\nJeśli interesujesz się DevOps i chcesz wiedzieć coś więcej niż tylko jakich narzędzi użyć, to jest to obowiązkowa lektura.\nPoniżej znajdziesz 10 najważniejszych według mnie wniosków z raportu. A jeśli nie chcesz się rejestrować, aby pobrać raport to stąd pobierzesz go bezpośrednio.\nZanim przejdziesz do 10 punktów to kilka ciekawostek o nim. Raport State of DevOps w tej formie ma już 8 lat, Tegoroczna edycja bazuje na 33000 odpowiedzi, z czego 1% pochodzi z Polski (dobrze, że istniejemy na tej mapie).\nRaport mówi, że 54% organizacji wdraża oprogramowanie na kontenerach, a 42% na maszynach wirtualnych. Całkiem nieźle!\nWysokie zaufanie, a nie szukanie winnych.\nTo jest kluczowe dla bezpieczniejszego dostarczania oprogramowania. Nie procedury, nie szkolenia, nie technologie, a utworzenie dobrej kultury pracy jest najistotniejsze.\nJa się wciąż uczę, że zamiast szukania winnych lepiej szukać rozwiązania. Nie jest to najłatwiejsze, szczególnie z widocznymi naleciałościami nieogarniętych menedżerów, ale to jedyna droga.\nUżycie cloud jest skorelowane z wysoką wydajnością organizacji.\nNiezależnie czy chmura publiczna, wiele chmur, rozwiązania hybrydowe czy chmur prywatna - użycie któregoś z tych rozwiązań ewidentnie pomaga szybciej dostarczać i lepiej zarządzać wdrożonym oprogramowaniem. Chodzi głównie o automatyzację i dostępność usług w trybie “self service”.\nA co jeśli nie możesz iść w chmurę publiczną, a OpenStack na chmurę prywatną nie jest kuszącym rozwiązaniem (i dość ciężkim w utrzymaniu)? Pozostaje Kubernetes, który w mojej opinii najlepiej podnosi poziom automatyzacji dla środowisk on-prem.\nSzybkie dostarczanie softu nie wystarczy. Musi iść w parze z czymś jeszcze.\nChodzi o zapewnieniem stabilności po wdrożeniu. Czyli wracamy do przeciągania liny między Dev (szybkość, nowe funkcje) i Ops (stabilność, “jeśli działa to nie psuj”).\nAby wszystko grało jak trzeba to należy zapewnić praktyki od początku do końca, czyli szybko wdrożyć, ale też przez praktyki SRE utrzymać aplikację, stosować metryki, reagować i usprawniać. Oczywiście wszystko z naciskiem na automatyzację.\nDwie praktyki wzmacniające pozostałe.\nSą to Continuous Delivery i powszechne użycie kontroli wersji (git). Wzmacniają one inne praktyki takie jak “Everything as code” i są obecne w organizacjach, które są liderami w dziedzinie dostarczania softu i jego utrzymania.\nJak nie wiesz od czego zacząć transformację u siebie to zacznij zatem od trzymania wszystkiego w kodzie i budowania potoków CI/CD.\nDokumentacja nie jest już potrzebna.\nSpełniają się marzenia niektórych - nie trzeba już pisać dokumentacji. No może nie do końca, bo z badania wynika, że dokumentacja powinna się automatycznie generować i aktualizować. To ma sens - wszystko w kodzie, łącznie z dokumentacją.\nTo co - od teraz implementujemy “Documention-as-Code”?\nMulti-cloud jest już dość powszechny\nStrategia multi-cloud używana jest głównie ze względu na zapewnienie dostępności (tak, awarie się będą zdarzać) i unikalne cechy danych dostawców chmur.\nWiększa elastyczność pracy to jest to co tygrysy lubią najbardziej.\nPrzynajmniej te tygrysy pracujące w IT. Taka praca zdalna, dobieranie własnych godzin pracy i narzędzi jest skorelowane z lepszymi wynikami i większym zadowoleniem z pracy.\nZatem masz już na to podkładkę - pokaż ten kawałek raportu przy negocjacjach o ile takowe się pojawią u Ciebie w organizacji.\nJeden element staje się krytyczny dla bezpieczeństwa.\nTym elementem jest łańcuch dostaw dla aplikacji. Raport wskazuje na dwa wyłaniające się standardy - SLSA, NIST SSDF.\nPrzykład tego jak rosjanie wykorzystanie nieszczelności w procesie dostarczania oprogramowania w SolarWinds wszystkim uświadomił jak newralgiczny staje się to element.\nMożna to podciągnąć pod podejścia przesunięcia w lewo bezpieczeństwa, ale z dodatkowymi, konkretnymi praktykami do zaimplementowania.\nPozostawanie w tyle ma konsekwencje.\nOrganizacje, które nie wdrożyły dobrych praktyk z obszaru DevOps nie tylko są na szarym końcu w rankingach dobrych firm do zatrudnienia się, ale też cechuje je duża rotacja związana z szybkim wypaleniem zawodowym.\nZbyt dużo chaosu, w większości niezaplanowane prace, słaba atmosfera - to efekt kuli śnieżnej, który tylko napędza złą passę. Pamiętaj o tym w rozmowach z mniej uświadomionymi menedżerami, gdyż oni też są głodni sukcesu, a nie zrobią tego bez dobrych ludzi.\n","tags":["cloud","cloud-native","kubernetes"],"title":"Newsletter #46 - 10 najważniejszych rzeczy z nowego raportu DevOps"},{"categories":["newsletter"],"date":"September 27, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/45/","section":"newsletter-archive","summary":"Pandemia przyniosła wiele problemów, ale też oswoiła z konieczności firmy do pracy zdalnej. I jest jedna, bardzo ważna korzyść z tego wynikająca.\nTo podróżowanie i praca skądkolwiek. Znane często pod pojęciem workation . A dlaczego o tym piszę? Bo sam wybieram się na takowe w przyszłym tygodniu. Uciekam od psującej się pogody i wykorzystuję okazję jaką daje mi swoboda pracy z dowolnego miejsca.\nJako pracujący na własny rachunek nie muszę tego uzgadniać, ale nawet jakbym pracował dla firmy to i tak większość ogłoszeń dla DevOps jest oznaczona jako “Fully remote”. To niesamowity przywilej i powinniśmy naprawdę to doceniać.\nWiele ludzi wróciło lub powoli wraca do biura. I dotyczy to również firm IT. Począwszy od Google, Netflix, Amazon, Microsoft i wiele innych - wszystkie one w jakiś sposób uniemożliwiają taką swobodę pracy. Albo oferują tryb hybrydowy, albo dla wybranych tryb zdalny.\nJa osobiście lubię pracę z biura, ale perspektywa pracy w miejscu, gdzie jest wciąż słonecznie i mniej szaro, napawa mnie ekscytacją.\nTo oczywiście wybór każdego, ale życzę Ci drogi czytelniku, abyś też miał taką swobodę. W końcu liczą się na końcu doświadczenia i im jest ich więcej tym lepiej je później sobie przypominać.\nPozostaje tylko utrzymanie się na rynku, aby firmy oferujące takie pozycje “Fully remote” waliły do nas drzwiami i oknami. Ja nie znam lepszego sposobu jak ciągłe rozwijanie portfela umiejętności i to, że to czytasz świadczy o Twoim zaangażowaniu w rozwój - tak trzymać!\nI jeszcze jedno - w związku z moją podróżą i przygotowaniami do niej, nie będzie przyszłotygodniowego newslettera. Obiecuję, że odrobię z nawiązką w kolejnym!\nPo co czytać książki Po dłuższej przerwie opublikowałem kolejny odcinek vloga. Tym razem opowiadam o tym czy warto czytać książki. Skoro cała wiedza jest w internetach to jaki sens ma czytanie książek?\nNiektórzy nie czytają i radzą sobie wyśmienicie to może to już nie ma sensu? A jeśli już to jakie i jak je czytać?\nNo i czy sama wiedza wystarczy? Do obejrzenia tutaj.\nKolejny tool do troubleshootingu mikroserwisów Nazywa się coroot i wygląda zacnie. Kolejne wykorzystanie eBPF i przypuszczam, że nie ostatnie.\nNowy Terraform 1.3 Wyszedł nowy Terraform 1.3. Czy są rewolucyjne zmiany? Nie.\nJest lepsza obsługa dyrektywy moved i wsparcie dla opcjonalnych pól w typach zmiennych. Poza tym wszystko po staremu. Czyżby Terraform już się stabilizował i powoli starzał?\nInstancje ARM najlepsze na AWS Chcesz oszczędzić lub też wykorzystać właściwości architektury ARM? Z tego porównania wynika, że najlepiej stawiać instancje ARM na AWS, bo najszybciej i najtaniej.\nSzkoda, że nie ma w porównaniu instancji od Oracle. Jeśli chcesz sam sprawdzić jak sobie radzą to mój przepis na darmowy klaster Kubernetesa pomoże Ci w postawieniu takiego środowiska za friko.\n","tags":["arm","aws","cloud","ebpf","edukacja","rozwój","terraform"],"title":"Newsletter #45 - Najlepsza korzyść pracy zdalnej"},{"categories":["newsletter"],"date":"September 20, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/44/","section":"newsletter-archive","summary":"Ten “odcinek” newslettera jest jednym z tych mniej technicznych.\nMoże to przypadek (naprawdę niewiele się wydarzyło ostatnio), a może to też przy okazji publikacji nowego odcinka podcastu i tematów w nim poruszanych.\nDevOps to nie tylko technologia i dlatego kolejny raz nie uciekam od tych tematów rozwojowych.\nTym razem przekornie przedstawiam listę 10 rzeczy, które utrwalają perfekcjonizm. Listę przygotowałem na podstawie moich osobistych doświadczeń i przemyśleń.\nWidzenie tunelowe\nTo jest zjawisko, gdzie skupiasz się tylko na wąskim polu. Nie widzisz innych rozwiązań, albo też nie bierzesz pod uwagę alternatywnej wersji lub innej interpretacji rzeczywistości. To jest pokrewne z punktem 6, ale wynika bardziej z przyzwyczajeń do jednego stylu działania i myślenia.\nWaterfall\nTak, uważam, że działanie w trybie podobnym do waterfalla, gdzie działamy długi czas bez przedstawienia nieidealnej wersji szerszej publiczności utrwala perfekcjonizm. Jest to wygodne, pochłania dużo czasu i doskonale wzmacnia poczucie, że to “jeszcze nie teraz”.\nI nie - Scrum nie jest rozwiązaniem, ale szukanie opinii będącej częścią podobnych metodyk, jest otworzeniem się na krytykę i dużym krokiem do przodu.\nFixed mindset\nPojęcie pochodzi ze słynnej książki “Mindset” i jest przeciwieństwem umysłu nakierowanego na rozwój (“growth mindset”).\nMnie osobiście trafia jak słyszę, że komuś się udało, bo jest zdolny, urodził się taki odważny (jakby ludzie sukcesu się nie bali) i wiara w to, że odgrywasz tutaj wyznaczoną z góry rolę.\nPrzestawienie na jasny podział na rzeczy, na które nie masz faktycznie wpływu i na takie, które są tylko Twoją odpowiedzialnością, jest niesamowicie motywujące (choć trudne).\nCzęste oglądanie social media\nSprawdzanie jak to innym wspaniale się wiedzie, jak uśmiechnięci cieszą się życiem, kolejnym sukcesem i nie mają zmartwień ani problemów. To nieszczęście naszych czasów, że tak łatwo możemy kreować rzeczywistość dla innych przez kilka ustawionych zdjęć, podkoloryzowaniem faktów i przedstawieniem czegoś w super-nieobiektywny sposób.\nNikt nie chce czytać o porażkach ani też o ciężkiej pracy. Z czasem jednak warto doceniać tą mniej kolorową rzeczywistość i zaakceptować ten realny obraz. Częste scrollowanie buduje jednak często ten fałszywy obraz.\nRozmyślanie zamiast działania\nTo moje ulubione! Myślenie o tym jak to bym zrobił, aby było wystarczająco dobre. Jakie to uspokajające i zwalniające z działania. W końcu nie mogę zacząć jeśli nie będzie wszystko dopięte i zgodne z najlepszymi praktykami.\nMyślenie jest potrzebne, ale nie może stać na drodze działania. Tylko działanie pozwala iść do przodu i ostatecznie usprawniać nasze dzieło. Często jednak pozwala zrozumieć, że usprawnienie takie ma jakiś kres.\nEfekt potwierdzenia\nCzyli tzw. “confirmation bias”. I znowu jest to naturalna nasza potrzeba szukania tylko faktów, które potwierdzą już coś co wiemy lub w co wierzymy. Jest to straszna broń naszego umysłu i ciężko się od tego uwolnić.\nJa podejmuję wysiłek, aby zmusić się do zadania sobie pytania “a co jeśli jest inaczej?”. Świat nie jest czarno-biały i poznanie innej perspektywy uwalnia pokłady kreatywności oraz ciekawości.\nKrótkowzroczność\nCzy to co myślisz, że ma tak kolosalne znaczenie będzie je nadal miało za za 10 minut, 10 miesięcy czy za 10 lat?\nWydaje nam się, że tak wiele możemy zepsuć i że wszystkie te niedoskonałości będą miały olbrzymie znaczenie. Jednak tak naprawdę w dłuższej perspektywie to nie ma takiego znaczenia, albo nie ma go w ogóle!\nSprawdź sam - pewnie popełniłeś wiele błędów, ale tylko promil z nich miał jakiś większy wpływ na przyszłość.\nStrach przed zmianą\nNasza pierwotna potrzeba status quo - niech będzie jak było, bo to przynajmniej jest znane. To czego nie znamy uwalnia naturalny strach. Ale co by było, gdyby wszyscy się tego strachu słuchali?\nNie wyszlibyśmy z jaskiń i wciąż uganiali się za zwierzyną o ile nie wyparłyby nas inne gatunki. No i oczywiście o komputerach też można byłoby zapomnieć.\nStrach ma wielkie oczy, ale jest naturalny. Ci co idą do przodu też się boją, ale oswajają się z tym uczuciem i przy kolejnych próbach jest to dla nich łatwiejsze. Tak było u mnie i tak będzie pewnie u Ciebie.\nUkrywanie wad\nGranie na kogoś kto ma tylko zalety i zaprzecza wręcz istnieniu tej słabszej strony jest po prostu naiwne.\nJeśli ktoś przede mną odsłoni swoją mniej perfekcyjną stronę, to od razu zdobywa moje większe zaufanie.\nTo przejaw dojrzałości i akceptacji, która jest chyba największym bodźcem do rozwoju.\n**Bezwzględność\n** Możesz się katować kolejnymi niedoskonałym rozwiązaniem, działaniem i szukać ideału. Ale łatwiej jest (i są na to badania) zastosować wobec siebie łagodniejsze podejście, gdzie jesteś bardziej litościwy dla siebie i swoich niedoskonałości.\n","tags":["perfekcjonizm","rozwój-osobisty"],"title":"Newsletter #44 - 10 rzeczy utrwalających perfekcjonizm"},{"categories":null,"date":"September 19, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/14/","section":"podcast","summary":"Dlaczego się obawiałem tego nagrania? Miałem swoje powody, ale strasznie się cieszę, że w końcu udało się mi spotkać z Mariuszem Gilem. To była jedna z najciekawszych rozmów w moim podcaście!\nA dlaczego? Bo poruszyliśmy naprawdę ciekawe i ważne tematy. Posłuchaj tego odcinka jeśli chcesz się dowiedzieć:\nJak zostać rozchwytywanym freelancerem jak Mariusz? Czy sesje zdalne Event Stormingu mogą się udać? Jaką wpadkę zaliczył Mariusz na rozmowie rekrutacyjnej? Jeśli uciekać od PHP to gdzie? Dlaczego menedżerstwo może nie być najlepszą ścieżką? Co zrobić, aby wyzbyć się wygórowanych oczekiwać i szukać tylko niedoskonałości? Książka “How to be an Imperfectionist” - https://lubimyczytac.pl/ksiazka/292004/how-to-be-an-imperfectionist-the-new-way-to-self-acceptance-fearless-living-and-freedom-from\n","tags":["biznes","freelance","perfekcjonizm","rozwojosobisty"],"title":"14 - O perfekcjonizmie z Mariuszem Gilem"},{"categories":["newsletter"],"date":"September 13, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/43/","section":"newsletter-archive","summary":"Zapomnij o książkach, kursach i wszystkich dobrych radach. Ja postanowiłem zamiast chłonąć kolejne elementy wiedzy robić coś znacznie lepszego i trudniejszego.\nZacząłem eksperymentować. Moim największym eksperymentem jaki obecnie prowadzę to poświęcenie się niemalże w 100% na przygotowywaniu konkretnych treści dla polskiego obszaru DevOps. Ale tego jest więcej, bo pewnie widziałeś moje krótkie filmy na YouTube/Instagram/TikToku, słuchałeś podcastu, widziałeś może moje ostatnie vlogi i kilka innych.\nDroga od wiedzy o czymś do jej praktycznego wykorzystania jest długa i tylko działając jestem w stanie sprawdzić czy to się aplikuje do mojego przypadku, mojej osobowości, moich wartości i moich celów.\nMa to też swoje słabe strony. Przede wszystkim poświęcam sporo czasu na te eksperymenty, poświęcam też środki finansowe, ale też zmagam się z rozczarowaniem, które przychodzi czasem jeśli nie idzie to po mojej myśli. Ta część nauki jest najtrudniejsza, ale też bez niej nie mógłbym pójść dalej myśląc “Aha, czyli to nie działa jak myślałem, a zatem czas spróbować czegoś innego”.\nEksperymenty to wyjście z ciepłej strefy komfortu. Polecam, ale pod warunkiem, że jesteś również gotowy na naukę czegoś o sobie.\nStabilny agent Vault dla Kubernetes Dobra wiadomość dla tych co nie wyobrażają sobie działania Kubernetes bez Vault. HashiCorp ogłosił wydanie wersji 1.0 narzędzia vault-k8s.\nTo jest dobra wiadomość jeśli oczywiście nie wybrałeś integracji za pomocą ExternalSecerts lub oficjalnego sterownika CSI. Ten ostatni pokazywałem nawet w ramach mojego wideo o nowościach w Kubernetes 1.25.\nNowe ficzery Tanzu od VMware VMware pochwalił się nowościami w swojej dystrybucji Tanzu. Mi od razu rzuciła się jedna rzecz - wsparcie dla Jenkins. I wiem, że są tacy co Jenkinsa kijem nie tkną, bo za stary, za brzydki, za nienowoczesny, za mało cloudowy itp. Projekt ten jakoś ma to w sumie gdzieś i umrzeć nie chce, a za to jak widać jest wciąż dość popularny.\nPoza tym jest obietnica wersji LTS, wsparcie dla GitOps (no w końcu) oraz dużo “enterprajsowych ficzerów”. Dobrze, niech rosną, bo nie może być tylko OpenShift na tym rynku.\nAmbient Mesh od Istio to spora rewolucja Istio wypuściło wersję 1.15 i pewnie nie pisałbym o niej gdyby nie jedno ogłoszenie. To Ambient Mesh.\nCo to? To lepsze podejście do budowania Service Mesh, które nie bazuje na kontenerach proxy doczepionych do każdego kontenera każdej aplikacji, a dwuwarstwowym podejściu.\n","tags":["cloud","docker","istio","kubernetes","rozwój","rozwój-osobisty","tanzu","vault"],"title":"Newsletter #43 - Nie znam lepszego sposobu na uczenie się"},{"categories":null,"date":"September 5, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/13/","section":"podcast","summary":"“Don’t Stapp me now” jak mówi o sobie sam Piotr i faktycznie bardzo miło się nam rozmawiało, że aż trudno było przerwać.\nTym razem usiedliśmy porozmawiać o świecie Microsoftu, Open source i Linuksa. Piotrek wyznał, że musi używać Linuksa, ale chyba już się przyzwyczaił.\nPoza tym wyjawiał dlaczego lubi pracować z frontendem i dlaczego również biznes ceni sobie ten obszar.\nJeśli chcesz się dowiedzieć o tym oraz o również o:\nCo ma wspólnego DevOps z Microsoft MVP? Jak zmienił się Microsoft przez ostatnie lata? Dlaczego kontenery Windows to zło? Czy warto wciąż ufać ludziom czy jednak trzeba mieć “papiery” na złe czasy to posłuchaj tego odcinka podcastu “Rozchmurzony”.\n","tags":["devops","kubernetes"],"title":"13 - O DevOps i Open source z Piotrkiem Stappem"},{"categories":["pl"],"date":"September 2, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/pl/czym-jest-zasada-womf/","section":"pl","summary":"Czym jest WOMF?\nJest to zasada, która mi bardzo pomogła i zmniejszyła moją frustrację. WOMF to zasada \u0026ldquo;Work On Me First\u0026rdquo;, czyli zaczynam zmianę od siebie. Kiedyś na siłę wręcz szukałem sposobów na zmianę zachowań innych lub byłem po prostu sfrustrowany tym, że inni nie myślą jak ja.\nJakie to było głupie i naiwne. WOMF jest pochodną oddzielenia rzeczy, na które masz wpływ i te, na które wpływu nie masz. Dorzucam tylko element ciężkiej pracy nad zmianą własnych przekonań i akceptacji faktu, że to kiedyś ja miałem dziwne, czasem wręcz głupie postrzeganie świata.\nAkceptacja, że mogę być tylko mniej głupszy jest uwalniająca. Szczególnie dla mnie - osoby, której perfekcjonizm wszedł za głęboko i musi z niego powoli wychodzić.\nNie oczekuję, że się inni zmienią chociaż często bardzo bym chciał. To naiwne myślenie. Szkoda energii, którą mogę spożytkować inaczej.\nStosuję WOMF i wrzucam na luz, bo praca innych nad sobą to nie mój interes ani moja odpowiedzialność.\n","tags":["biznes","perfekcjonizm","rozwój-osobisty"],"title":"Dzięki WOMF nie przejmuję się głupotami"},{"categories":["newsletter"],"date":"August 30, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/41/","section":"newsletter-archive","summary":"A co mi się udało? Znalazłem czas i poskładałem informacje o szkoleniach, które opublikowałem na stronie. A dlaczego nie było łatwo? A top długa historia. Jej część nawet nagrałem, bo od teraz cyklicznie nagrywam vloga, w którym opowiadam o tym co robię, jak robię i dlaczego coś robię.\nJeśli masz wolne kilka minut rano to zerknij na mój kanał na YouTube. A teraz zapraszam do innych nowości.\nObejrzyj ostatni LIVE o 3 ciekawych funkcjach w nowym Kubernetes 1.25 Nie udało Ci się dotrzeć na LIVE w ostatni piątek? Koniecznie obejrzyj powtórkę. Poza ciekawą przygodą związaną z moim kubkiem omawiam 3 ciekawe funkcje:\nKontenery efemeryczne do debugowania Podsystem CSI dla przestrzeni dyskowej Finalne wycięcie z Kubernetes PodSecurityPolicy i zastąpienie go PodSecurity Do każdego pokazuję też małe demo. Obejrzyj wideo tutaj.\nDługo mi to zajęło, ale w końcu opublikowałem informacje o moich szkoleniach Wiele osób pisało do mnie kiedy będą informacje o szkoleniach. To z przyjemnością informuję, że już są. Póki co dostępne są trzy:\nFundamenty Kubernetes - solidne podstawy pracy z Kubernetesem Masterclass o zarządzaniu klastrem - coś ponad podstawy dla tych, którzy chcą wiedzieć i umieć więcej o zarządzaniu klastrem Masterclass o bezpieczeństwie Kubernetes - w końcu skumulowana wiedza o bezpieczeństwie Kubernetesa w postaci praktycznego warsztatu Obecnie prowadzę szkolenia zamknięte dla firm, ale do każdego szkolenia otworzyłem też listę na szkolenie otwarte. Jeśli zbierze się odpowiednia liczba chętnych to wyślę szczegóły i propozycje terminu.\nCloudFront w AWS obsługuje już HTTP/3, a co z resztą? HTTP w wersji 3, protokół znany wcześniej jako QUIC, zbliża się wielkimi krokami. Świadczy o tym ogłoszona niedawno przez AWS możliwość używania ten nowej wersji w ich usłudze CloudFront. Teraz czekamy na innych, którzy nie będą chcieli zostać w tyle.\nZ mojej perspektywy czekam też na obsługę HTTP/3 w popularnych serwerach HTTP, które mogłyby tą funkcjonalność udostępnić jako kontrolery Ingress.\nObecnie HAProxy wspiera to eksperymentalnie, Envoy chyba na całego, a Nginx jeszcze nie jest do końca gotowy.\nTo chyba i tak lepiej niż adopcją IPv6 ;)\nWyłączaj pule węzłów w AKS Rzadko piszę o o Kubernetesie od Microsoftu, a tym razem wydali coś ciekawego. Jeśli używasz ich usługi AKS to teraz możesz wyłączyć pule węzłów. Nie musisz ich kasować i odtwarzać, a jedynie wyłączyć jak zwykłe serwery. To chyba kolejny ukłon w stronę tych, którzy obawiają się wysokich kosztów klastra. Szczególnie, że jako jeden z niewielu dostawców Azure nie pobiera opłat za utrzymywanie klastra (Control Plane).\nNapisz swój własny scheduler lub przynajmniej pobaw się symulatorem Scheduler (czy też po polsku “planista”) w Kubernetesie to naprawdę ciekawy i złożony kawałek oprogramowania. Ale jest też przez to potężny i daje duże możliwości w sterowaniu dystrybucją podów po klastrze.\nPolecam sprawdzenie jak napisać własny scheduler lub uruchomić symulator i sprawdzić jego różne opcje.\nJeśli interesuje Cię ten temat to warto sprawdzić też mój Masterclass, gdzie pokazuję praktycznie jak użyć wielu zaawansowanych opcji sterowania rozłożeniem podów i kierowania ruchem do nich.\n","tags":["aks","aws","cloudfront","http3","kubernetes"],"title":"Newsletter #41 - W końcu się udało, ale nie było łatwo"},{"categories":["newsletter"],"date":"August 23, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/40/","section":"newsletter-archive","summary":"Kończy się chyba okres urlopowy, bo zaczynają spływać ciekawe nowości i pojawiać się nowe wersje projektów. Z pewnością najciekawszą jest nowy Kubernetes, który jeśli wszystko dobrze pójdzie to zostanie wydany w dniu wysyłki tego newslettera.\nCzas na CDK for Terraform zamiast HCL? HashiCorp poinformował o wydaniu wersji stabilnej (GA) projektu “CDK for Terraform”. To co - zapominamy o HCL i przykrywamy go naszym ulubionym językiem programowania? Mamy teraz z czego wybierać, bo oprócz Typescript, C#, Javy i Pythona doszło w tym wydaniu jeszcze Go.\nSzach-mat Pulumi. I odpowiadając na pojawiające się pytania - tak, zdecydowanie będzie sporo materiałów o Terraform i multi-cloud. Mój backlog się zapełnia i nie pominę również CDK TF. W końcu bez Terraform nie ma dobrego “Everything as Code” z (multi)cloud jest to ogromna część DevOps.\nTo już pewne - Multi-cloud to nie przyszłość, a teraźniejszość Zostając jeszcze przy HashiCorp to opublikowali raport z ankiety, z której wprost wynika, że nie ma odwrotu od muli-cloud. W takiej czy innej formie już to podejście jest częścią większości organizacji.\nA co jest największą barierą w implementacji multi-cloud (i chyba cloud ogólnie)? Jak zwykle bezpieczeństwo. Dla mnie jest to wciąż zadziwiające, bo mam wrażenie, że temat ten jest jednak traktowany po macoszemu. Narzędzi jest mnóstwo co było widać chociażby na stoiskach na tegorocznym KubeCon EU, a organizacje często zmagają się z ogarnięciem podstaw bardziej złożonych konfiguracji.\nAle to nie koniec. Bo kolejnym powodem jest… brak ludzi. To może wyjaśnia też obawy o bezpieczeństwo, bo skoro ludzi jest mało to ekspertów tym bardziej.\nI ten newsletter jest właśnie po to, aby nas ekspertów było więcej.\nTrivy w Docker Desktop i z dodatkowymi funkcjami Najbardziej popularny skaner bezpieczeństwa dla kontenerów dostępny jest jako rozszerzenie dla Docker Desktop. Jako użytkownik Maca wyklikałem to sobie i działa. Jest pięknie, są ikonki, lepsze kolorki, ale wciąż to CLI jest dla ekspertów. To rozszerzenie to kolejny powód, aby przekonać firmy do zakupu licencji na Docker Desktop. I może dobrze - niech przynajmniej tyle mają z rozpoczęcia rewolucji z kontenerami.\nDo tego samo Trivy (niekoniecznie w Docker Desktop) zdobyło super ciekawą funkcję. Obok skanowania obrazów kontenerów jest ono teraz skanerem CSPM (Cloud Security Best Practices). Obecnie wspiera AWS, ale też skanuje podatności klastrów Kubernetesowych!\nTo naprawdę wspaniałe narzędzie i jeśli go jeszcze nie używałeś to instaluj szybciutko.\n","tags":["aws","cdk","docker","kubernetes","terraform","trivy"],"title":"Newsletter #40 - Skanuj Kubernetes i AWS z Trivy"},{"categories":["newsletter"],"date":"August 16, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/39/","section":"newsletter-archive","summary":"Dziękuję za obecność na piątkowych live’ach. Postaram się je teraz robić cyklicznie i jeśli masz jakiś pomysł, który mogę poruszyć to pisz do mnie śmiało - najprościej odpowiedz na tego maila.\nDzięki WOMF nie przejmuję się głupotami Czym jest WOMF? Jest to zasada, która mi bardzo pomogła i zmniejszyła moją frustrację. WOMF to zasada \u0026ldquo;Work On Me First\u0026rdquo;, czyli zaczynam zmianę od siebie. Kiedyś na siłę wręcz szukałem sposobów na zmianę zachowań innych lub byłem po prostu sfrustrowany tym, że inni nie myślą jak ja.\nJakie to było głupie i naiwne. WOMF jest pochodną oddzielenia rzeczy, na które masz wpływ i te, na które wpływu nie masz. Dorzucam tylko element ciężkiej pracy nad zmianą własnych przekonań i akceptacji faktu, że to kiedyś ja miałem dziwne, czasem wręcz głupie postrzeganie świata.\nAkceptacja, że mogę być tylko mniej głupszy jest uwalniająca. Szczególnie dla mnie - osoby, której perfekcjonizm wszedł za głęboko i musi z niego powoli wychodzić.\nNie oczekuję, że się inni zmienią chociaż często bardzo bym chciał. To naiwne myślenie. Szkoda energii, którą mogę spożytkować inaczej.\nStosuję WOMF i wrzucam na luz, bo praca innych nad sobą to nie mój interes ani moja odpowiedzialność.\nDwa YouTube LIVE - Jenkins i GitOps Ostatnie w dwa piątkowe poranki pokazywałem interesujące tematy. Zacząłem od Jenkinsa, który dobrze obsługiwany może być całkiem przydatny dla tworzenia procesów CI/CD - dla aplikacji na Kubernetesie lub poza.\nA w ostatni piątek pokazywałem najfajniejsze rzeczy związane z GitOps w jego najlepszej według mnie implementacji - Argo CD.\nZapraszam do obejrzenia powtórek i do udziału na żywo, bo pytania na koniec są dla mnie motywacją do robienia tego rodzaju nagrań, a dla Ciebie możliwością zadania nawet najbardziej kłopotliwego dla mnie pytania.\n","tags":["perfekcjonizm","rozwój-osobisty"],"title":"Newsletter #39 - WOMF nie uratuje przed upałami, ale dla mnie działa cuda"},{"categories":["newsletter"],"date":"August 2, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/38/","section":"newsletter-archive","summary":"Ciepłe lato, a z nim sezon ogórkowy. Niewiele się dzieje również w świecie DevOps i Kubernetes. Poza moim szkoleniem oczywiście, ale o nim już dużo napisałem.\nDlatego też dzisiaj pozwolę sobie na trochę refleksji i jeśli masz chwilę to zapraszam do przeczytania, a jeśli nie masz czasu to oczywiście zapraszam na jutro, bo tam będzie sporo “mięcha”.\nCiężka praca nie popłaca? TL;DR; Zakasaj rękawy i walcz o swój sukces\nNiedawno skończyłem czytać ciekawą książkę: “Don\u0026rsquo;t Trust Your Gut: Using Data to Get What You Really Want in Life”. To kolejna po “Factfullness” pozycja, gdzie poruszany jest temat bazowania na faktach podczas podejmowania decyzji lub po prostu budowania własnej opinii o otaczającym świecie.\nI po tej lekturze nabrałem jeszcze większej motywacji do pracy nad materiałami. Może też tak miałeś, że wydawało Ci się, że aby realizować marzenia to trzeba dużo szczęścia, urodzić się odpowiednio, mieć super wygląd lub inne rzeczy, na które nie masz wpływu.\nJa tak miałem, ale od jakiegoś czasu jestem przekonany, że są to tylko wygodne wymówki, aby usiąść, założyć ręce i robić tylko to czego ktoś od nas wymaga. Bo w końcu nie jesteś Markiem Zuckerbergiem, Billem Gatesem lub Stevem Jobsem i nie zacząłeś budować firmy w garażu swoich rodziców w wieku kilkunastu lat.\nNo bo sukces musi być od razu gigantyczny i widoczny w social media (fajne fury, wakacje z drinkami na plaży i takie tam. No przecież niemożliwe, że tu głównie chodzi o coś strasznie nudnego - o ciężką pracę i wytrwałość, prawda?\nChcemy wierzyć w te bajki o tym jak ktoś niemalże bez wysiłku stał się gwiazdą. Miał pewnie tzw. “predyspozycje” lub może “talent”. Media podsycają te opowieści, bo to się świetnie sprzedaje. Nikt nie chce czytać lub oglądać nudnej opowieści o harówce i porażkach. Lubimy bajki. A nowoczesne bajki to te o superbohaterach i dlatego Disney wie co robi kręcąc najbardziej intratny biznes ostatnich dziesięcioleci (wypuszcza kolejne filmy i seriale na podstawie komiksów Marvela).\nA dane pokazują co innego. Tylko promil ludzi osiąga sukces przypadkiem (a to też nie do końca prawda - polecam książkę). Cała reszta po prostu zakasa rękawy i zapiernicza.\nDla mnie bohaterem jest właśnie taka osoba. Ktoś kto wychodzi na ring i zmaga się z wewnętrznym krytykiem, perfekcjonizmem, ciężkim dniem/tygodniem/miesiącem i walczy o swoje. Mi jest bliżej do tego obrazu superbohatera.\nJeśli czytasz ten newsletter to kibicuję Twojej drodze. I choć nie ma dróg na skróty to będę starał Ci się dostarczać cennych wskazówek, bo ja się przewróciłem już nie raz. Najważniejsze, aby zawsze się podnosić.\n","tags":["biznes","devops","gitops","rozwój-osobisty"],"title":"Newsletter #38 - Znalazłem chyba najlepszy serwer Git do GitOps"},{"categories":null,"date":"July 31, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/12/","section":"podcast","summary":"W końcu udało mi się porozmawiać z Olą. I co to była za rozmowa! Najciekawszy fragment wydawać się może niektórym kontrowersyjny.\nWybraliśmy trochę niestandardowe podejście omawiając temat testowania. Wzięliśmy fikcyjną firmę Polsoftex i na jej przykładzie Ola opowiedziała o najlepszych praktykach… tak jakby.\nTo trzeba jednak usłyszeć, aby się przekonać o wyjątkowości naszej dyskusji. Poruszamy w niej takie wątki jak:\nCo jest największą przeszkodą w testowaniu?\nDlaczego testy infrastruktury są prostsze?\nJak pisać (bez)użyteczne testy?\nCzy ludzie od DevOps wykazują pokorę?\nKto nie powinien ich pisać?\nJaką rolę odgrywa sarkazm w IT?\nKsiążka Oli - \u0026ldquo;Kierunek jakość\u0026rdquo;\n","tags":["devops","kubernetes"],"title":"12 - O tym jak nie testować z Olą Kunysz"},{"categories":null,"date":"July 18, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/11/","section":"podcast","summary":"Czy developerzy potrzebują ludzi od infry? Czy Cloud lub Kubernetes cokolwiek tutaj zmienia? Czy DevOps jest faktycznie potrzebny?\nO tych oraz innych tematach rozmawiałem z weteranem polskich podcastów IT - Krzysztofem Kempińskim, twórcą podcastu “Porozmawiajmy o IT”. Zapraszam do wysłuchania i obejrzenia naszej rozmowy.\n","tags":["devops","kubernetes"],"title":"11 - O Dev i DevOps z Krzysztofem Kempińskim"},{"categories":["newsletter"],"date":"July 18, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/36/","section":"newsletter-archive","summary":"Jeśli planujesz Kubernetes on-prem to będziesz zadowolony. W końcu AWS popisał się z Kubernetesem\nCzekałem, czekałem i się doczekałem. AWS dodał obsługę bare-metal do swojej dystrubucji Kubernetesa. Szczegóły poniżej.\nSam już niewiele dotykam sprzętu odkąd możliwe jest zamówienie serwerów po API z chmury publicznej i to w dość rozsądnych pieniądzach. Jednocześnie Kubernetes jest idealnym przykładem, gdzie posiadając dużo “blachy” można pozbyć się dodatkowej warstwy abstrakcji w postaci wirtualizacji.\nHistoria zatacza trochę koło - kiedyś wirtualizacja była hitem, a teraz bez niej spokojnie da się obejść. Mi się osobiście to podejście podoba i czekam na więcej takich produktów/projektów.\nW końcu - EKS Anywhere na bare-metal! Jakiś czas temu opisywałem EKS Anywhere jako całkiem ciekawą platformę dla własnego Kubernetes. Narzekałem wówczas jedynie na brak wsparcia środowisk on-prem. No to teraz już nie narzekam!\nAWS ogłosił niedawno wsparcie dla instalacji tej dystrybucji na bare-metal. I nie mówię tutaj o własnych serwerach z vSphere, a o prawdziwym bare-metal - sama blacha bez wirtualizacji!\nW dokumentacji można znaleźć dużo ciekawych szczegółów jak np. Bootowanie po PXE i wykorzystanie interfejsów zarządzających IPMI do kontroli węzłów. Tak to ja rozumiem - to jest dokładnie właściwy sposób na provisioning klastrów na własnej infrastrukturze!\nChecklista adopcji podejścia GitOps Myślisz o adopcji GitOps? Pojawił się ciekawy artykuł, który opisuje 16 ważnych punktów przy wdrażaniu GitOps.\nCzęść z nich jest oczywista, ale zanim przejdziesz entuzjastycznie do obsługi wszystkiego z Gita to warto się zapoznać z tym co jest tam opisane.\nAha - a jeśli Cię interesuje podejście GitOps do wdrażania aplikacji to będę miał coś ciekawego. Ale póki co to tajemnica i szczegóły wyślę wkrótce.\nAlternatywa dla kubens/kubectx Nagminnie używam kubens i kubectx, ale znalazłem fajną alternatywę. Nazywa się kubeswitch i jest bardziej “wypasiona”, bo obsługuje aliasy, jest w stanie pobierać dane z Vaulta i nie modyfikuje globalnego pliku z konfiguracją.\nJa jestem w trakcie przesiadki, bo wydaje się być po prostu lepsze.\n","tags":["aws","cloud","eks","gitops","kubernetes"],"title":"Newsletter #36 - W końcu AWS popisał się z Kubernetesem"},{"categories":["newsletter"],"date":"July 11, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/35/","section":"newsletter-archive","summary":"Sam Kubernetes nie jest już młody, ale w jaki sposób ma on działać z czymś co ma prawie 40 lat? To proste - bez tego byłoby o wiele trudniej. Bo możliwe jest uruchomienie aplikacji komunikującej się wewnętrznie po adresach IP, ale chyba nikt tego nie używa. I dlatego DNS, bo o nim mowa, jest nieodzowną częścią środowisk Kubernetesowych.\nSzczegóły w moim nowym wideo, a to mi tylko przypomniało o tym jak Kubernetes jest zlepkiem znanych już technologii połączonych sprytnie w jedną całość. To zatem bardziej ewolucja niż rewolucja i fajnie to sobie uświadomić, że pomimo swojej złożoności to są to znane już od dawna elementy.\nJak działa DNS w Kubernetes? Zobacz moje nowe wideo z cyklu “Kubernetes od kuchni” od działaniu DNS w klastrze. Powstało ono z tematów, które przesłaliście w ankiecie - jeszcze raz dzięki! W szczególności Michałowi, który zaproponował ten konkretny temat.\nhttps://youtu.be/FLbV2cYKytg\nZ monolitu do mikroserwisów przez kontenery Tak się złożyło, że Kubernetes powstał w czasie, gdy popularnością cieszyła się architektura mikroserwisów. Do tego kontenery idealnie się nadawały do umieszczania w nich poszczególnych mikroserwisów zarządzanych i wdrażanych niezależnie.\nCzy to oznacza, że już wszyscy używają mikroserwisów? Ależ skąd! Dla nich jest ten ciekawy artykuł, który opisuje podejście migracji z monolitu do mikroserwisów.\nA czy Kubernetes jest tylko dla mikroserwisów? Też nie. Według mnie (i to samo znajdziesz w artykule) spokojnie da się uruchamiać monolity na Kubernetesie. Może to być w fazie przejściowej migracji lub nawet bez. Zawsze zyskujesz w ten sposób nowy poziom niezawodności, skalowalności (jeśli się da), zarządzania wdrożeniami i przenoszalności.\nBlue/Green dla puli węzłów w GKE Dobra wiadomość dla użytkowników Kubernetesa na GCP. Właśnie wprowadzili możliwość aktualizacji węzłów w trybie Blue/Green. Ci co widzieli moją prezentację o przygodach związanych z aktualizacją klastra wiedzą, że aktualizacje mogą być “ciekawym” wyzwaniem (szczególnie jeśli nie zadba się o jedną rzecz).\nNowy sposób obsługi tokenów dla Service Account i możliwe problemy Sam dowiedziałem się wielu ciekawych rzeczy z tego artykułu o obsłudze tokenów. Polecam tą lekturę jeśli chcesz się dowiedziec jak pod spodem Kubernetes zarządza tokenami i jak konta serwisowe uwierzytelniają się z API.\nMnie ten problem jeszcze nie dotknął, ale możesz natrafić na klaster (jak np. GKE od wersji 1.21) Kuebrnetesowy, który nie będzie miał już statycznych tokenów. Zatem jeśli używałeś ich do uwierzytelniania użytkowników w klastrze to upewnij się, że jeśli sam zarządzasz klastrem to nowa wersja nie włączy dynamicznych tokenów i rozwali ci uwierzytelnianie.\n","tags":["gke","kubernetes","ubuntu"],"title":"Newsletter #35 11.7.2022 - Kubernetes w parze z prawie 40-letnią technologią"},{"categories":null,"date":"July 4, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/10/","section":"podcast","summary":"Rozmowy z Tomkiem Onyszko są zawsze ciekawe. W tej dowiedziałem się o zaskakującej rzeczy o znanej osobie w światku IT.\nDzielimy z Tomkiem nie tylko wspaniałe imię, ale też introwertyczność, wiele poglądów na temat kultury organizacji oraz definicji DevOps.\nRóżni nas przekonanie co do tego, która chmura jest najlepsza i jeśli chcesz się dowiedzieć więcej to posłuchaj naszej rozmowy. Poruszamy w niej takie tematy jak:\nKto był największym introwertykiem IT zanim stał się sławny?\nTo czym jest ten DevOps - kultura, narzędzia czy stanowiska?\nJak budować kulturę w organizacji?\nCzy polskie firmy mogą realnie konkurować na zachodzie?\nJaka zapomniana już przez niektórych wiedza pozwoliła Tomkowi rozwiązać problem?\nKtóra chmura jest najlepsza (według Tomka oczywiście 🙂)?\n","tags":["devops","kubernetes"],"title":"10 - O kulturze w organizacjach z Tomkiem Onyszko"},{"categories":null,"date":"June 19, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/9/","section":"podcast","summary":"🧳 Czym jest tajemnicza walizka z czerwonym przyciskiem i co ma wspólnego z wystąpieniami publicznymi?\nOdpowiedź na to i inne pytania usłyszysz w mojej rozmowie ze Sławkiem Sobótką. Rozmawialiśmy długo i poruszyliśmy naprawdę ważne tematy takie jak:\n👨‍🏫 Jak wybierać dobrych trenerów na szkolenia (Sławek dzieli się swoim bogatym doświadczeniem na tym polu)?\n💪 Jak ważne są przekonania nie tylko dla dobrego samopoczucia, ale też dla zdrowia?\n💊 Nad jakimi projektami pracuje obecnie Sławek, którę pomogą wkrótce leczyć ludzi?\n🧑‍💻 Czy kariera w IT jest dla wszystkich?\n📈 Jak efektywnie się rozwijać w IT?\nObok tego Sławek zdradza od ilu koni mechanicznych według niego zaczyna się dobry 🚗 oraz opowie na pytanie dlaczego woli klocki od puzli.\n","tags":["devops","kubernetes"],"title":"9 - O rozwoju kariery ze Sławkiem Sobótką"},{"categories":null,"date":"May 2, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/8/","section":"podcast","summary":"Bez tego już sobie nie wybrażam poważnego projektu. Dlaczego Terraform zagościł u mnie i wielu organizacjach na stałe?\nCo ma w sobie to narzędzie, że tak wielu używa go do zarządzania infrastruktury chmury publicznej w stylu Infrastruture-as-Code?\nCzy Terraform jest tylko niszowym projektem czy może czymś więcej? Na czym polega jego uniwersalność?\nW tym odcinku podcastu “Rozchmurzony” przyglądam się bliżej fenomenowi Terraform.\n","tags":["devops","kubernetes"],"title":"Podcast \"Rozchmurzony\" #8 - Terraformacja chmur i Infrastructure-as-Code"},{"categories":null,"date":"April 18, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/7/","section":"podcast","summary":"Co spowodowało, że Kubernetes jest dzisiaj wszędzie? Dlaczego akurat temu projektowi się to udało?\nDlaczego w ogóle potrzebowaliśmy czegoś takiego jak Kubernetes? Czy Cloud nie wystarczył?\nDlaczego uważam, że to Kubernetes zapoczątkował większą rewolucję niż Cloud?\nJak wyglądało moje pierwsze zetknięcie z nim, trudne początki i jak sobie dałem rady poznać go dość dobrze?\nNajnowszy odcinek mojego podcastu w całości poświęcam fenomenowi Kubernetesa!\n","tags":["devops","kubernetes"],"title":"Podcast \"Rozchmurzony\" #7 - Na czym polega fenomen Kubernetesa?"},{"categories":null,"date":"April 4, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/6/","section":"podcast","summary":"💥 Czy wiesz najłatwiej zniszczyć reputację organizacji? Spowoduj, że dostarczane usługi będą często niedostępne. Budowana czasem przez lata reputacja szybko jest nadszarpnięta jeśli zarządzono ryzykiem awarii i nie obsłużono ich w odpowiedni sposób.\nW jaki sposób się tego ustrzec i projektowac systemy tak, aby byly odporne na awarie? Czy użycie chmury publicznej lub Kubernetes wystarczy? Czy są może jeszcze jakieś inne skuteczne sposoby?\nW tym odcinku przedstawię ci koncept “Design For Failure”, opowiem o najczęstszych przyczynach awarii oraz przedstawię skuteczne metody projektowania systemów tak, aby się ich ustrzec.\nOpowiem też dlaczego w przypadku firmy Boeing takie ekstremalne zaniedbania spowodowały śmierć 367 niewinnych ludzi i czego się możemy z tego nauczyć.\n","tags":["devops","kubernetes"],"title":"6 - Jak projektować systemy odporne na awarie?"},{"categories":null,"date":"March 21, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/5/","section":"podcast","summary":"🇵🇱 Dlaczego to właściwe Polacy są najlepszymi ludźmi od DevOps? Co widzą w nas zagraniczne firmy, które są w stanie płacić solidnie na nasze usługi? W jaki sposób my Polacy możemy być jeszcze bardziej doceniani w obszarze DevOps? I na jakiej właściwe podstawie uważam, że to my Polacy jesteśmy najlepsi DevOpsami?\nPosłuchaj tego najnowszego odcinka podcastu, aby poznać odpowiedzi i dowiedzieć się też o mojej misji związanej z DevOps w Polsce!\n","tags":["devops","kubernetes"],"title":"5 - Dlaczego to Polacy są najlepszymi DevOpsami?"},{"categories":null,"date":"February 28, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/4/","section":"podcast","summary":"Co daje zarządzanie błędami? Czy to w ogóle możliwe? W jaki sposób to robić? Co to ma w ogóle wspólnego z DevOps?\nW tym odcinku podcastu poznasz historię mojego oblanego certyfikatu do RHCA oraz historie innych, które pokazują jak podejście do błędów wpływa na naszą pracę i życie.\nDowiesz się też czym jest SLI, SLO i słynne SLA. Sprawdź jak wykorzystać ten koncept do rozwoju siebie i platformy, którą tworzysz lub zarządzasz.\nPosłuchaj jak świadomie zarządzanie ryzykiem przez takie podejście ułatwia szybszy rozwój, a jak nieodpowiednio używane może doprowadzić do zastoju.\n","tags":["devops","sre"],"title":"4 - Czym jest budżet błędów i jak go wykorzystać?"},{"categories":null,"date":"February 13, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/3/","section":"podcast","summary":"🤔 Co tak naprawdę dają certyfikaty? Jaki certyfikat przynosi najwięcej korzyści w DevOps?\nJakie certyfikaty warto zdawać, a jakich unikać? Czym jest trójkąt korzyści?\nW tym odcinku mojego podcastu opowiadam o tym kiedy i czy w ogóle warto posiadać certyfikaty branżowe.\nPrzedstawiam też moją osobistą listę przebojów certyfikacji na podstawie moich doświadczeń - dowiesz się, który certyfikat według mnie jest:\n- najłatwiejszy\n- najbardziej przydatny (najmniej tracący z czasem na przydatności)\n- najdziwniejszy\n- najtrudniejszy\n- przynoszący najwięcej korzyści\n","tags":["devops","kubernetes"],"title":"3 - Czy warto zdobywać certyfikaty?"},{"categories":null,"date":"January 28, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/2/","section":"podcast","summary":"Czy czułeś kiedyś że życie stawia Ci kłody pod nogi?\nSzczególnie jak jesteś pełny zapału i entuzjazmu, a zostałeś zderzony z brutalną rzeczywistością?\nJeżeli tak to posłuchaj jak wyglądała moja historia zdobycia mojej pierwszej pracy!\nDowiedz się jak w moim wypadku wyglądały pierwsze rozmowy i na jakie ciekawe przypadki natrafiłem. Opowiem też o tym dlaczego mój projekt hobbystyczny okazał się niezbędny przy mojej pierwszej pracy.\n","tags":["devops","kariera"],"title":"2 - Moje trudne początki ze zdobyciem pracy"},{"categories":null,"date":"January 28, 2022","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/podcast/1/","section":"podcast","summary":"No i stało się! Dołączam kolejne medium do już istniejącego kanału YouTube, tego newslettera i bloga (ten wkrótce przejdzie radykalną zmianę). Tym razem będzie mnie tylko słychać w ramach mojego podcastu Rozchmurzony.\nNazwa nie jest przypadkowa, gdyż chcę tam opowiadać o technologiach z obszaru DevOps, Cloud Native i oczywiście o Kubernetes, ale również o tematach miękkich. Głównie będą to obszary związane z rozwojem kariery, odblokowaniem siebie i wykorzystaniu swojego pełnego potencjału.\nNie wierzę, że tylko technologia wystarczy i aby iść dalej należy również poznawać inne obszary.\nA poniżej kilka informacji o samym podcaście.\nO czym będzie To co planuję to przede wszystkim:\nKubernetes, OpenShift, Docker i kontenery - to co tygrysy lubią najbardziej! Ciekawe historie z bojów z produkcji Przedstawienie najciekawszych projektów Cloud Native Wskazówki do efektywnej nauki i rozwoju Polecane książki (mini recenzje) I do tego pewnie inne rzeczy pojawiające się w trakcie, które będę przygotowywał do nagrań samodzielnych. Ale podcast to nie będę tylko ja.\nGoście Zdecydowanie tak - pojawią się goście i w miarę rozwoju podcastu będzie ich coraz więcej. Sam uwielbiam rozmawiać z ludźmi i będę tak dobierał gości, aby tematy rozmowy pomagały moim słuchaczom i były interesujące, a czasem może inspirujące.\nMam już wstępną listę, ale oczywiście nie będę jej zdradzał :)\nJak mogę słuchać? Podcast dostępny jest na większości platform do słuchania:\nApple Podcasts Spotify YouTube Gdzie mogę się dowiedzieć więcej o danym odcinku Obecnie najwięcej rzeczy jest na stronie Spreakera. Wkrótce też każdy odcinek będzie miał oddzielną podstronę na mojej głównej stronie o czym nie omieszkam poinformować.\n","tags":["podcast"],"title":"1 - O czym jest ten podcast"},{"categories":["pl"],"date":"December 30, 2021","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/pl/co-przyniesie-rok-2022-dla-devops/","section":"pl","summary":"Co to był za rok! Chyba nigdy tyle nie obejrzałem seriali na Netflix siedząc w domu, ale też nigdy nie przeczytałem tak wielu książek. A ilu rzeczy się też nauczyłem - dużo o technologii, a jeszcze więcej o sobie. Ile też konferencji się odbyło, które zostały przeniesione do online - niestety moim zdaniem niekorzystnie dla nich. Wyszły 3 wersje Kubernetesa, pojawił się Terraform 1.0 i było też dużo ciekawych, dużych awarii clouda. Oj działo się, nie powiem. Ale najważniejszym dla mnie był początek wydawania regularnego tego newsletter - to była wyśmienita decyzja! Postanowiłem tym razem wyciągnąć szklaną kulę i zabawić się we wróżbitę Tomasza :) Przedstawiam Ci moje przewidywania na rok 2022. Skupię się na technologii, DevOps i moich planach.\nKubernetes się starzeje dojrzewa To już nie nowość - Kubernetes to już standard. Projekt wciąż prężnie się rozwija, a jego API dojrzewa. Nie ma spektakularnych nowości i nie będzie ich zbyt dużo również kolejnych wersjach wydawanych w 2022. Taki los dobrych produktów - przestaje być o nich głośno, gdyż stają się częścią naszej codzienności. Podobnie było z Linuksem - kiedyś grupa fascynatów zaczynała go używać również na desktopach, a teraz to codzienność w całym świecie IT. Jednym z ważnych trendów jest dalsza modularyzacja Kubernetesa i wyodrębnienie poszczególnych komponentów spoza głównego kodu. Dotyczy to głównie aspektów sieciowych (to się już dzieje - pluginy CNI), ale też coraz częściej obsługi wolumenów (drivery CSI zamiast providerów w głównym kodzie). To powinno jeszcze przyspieszyć adopcję Kubernetesa na mniejszych chmurach i na środowiskach on-prem.\nTerraform standardem W końcu menedżerzy i dyrektorzy mogą spokojnie patrzeć jak ich działy IT wykorzystują Terraform do obsługi serwisów w chmurach. W końcu nie jest to jakaś wersja 0.X, a już 1.0 wydana w tamtym roku. Niektórzy mogą uśmiechnąć się z politowaniem, ale nawet czasem takie małe elementy mogą decydować o decyzji w wyborze narzędzia. To był ogólnie świetny rok dla HashiCorp i od niedawna jest spółką publiczną notowaną na nowojorskiej giełdzie. Sam Terraform pozostanie jeszcze bardziej wykorzystywanym narzędziem przez ludzi od DevOps. Podobnie jak w przypadku Kubernetes jego adopcji sprzyja modularyzacja. W końcu można go rozszerzać pisząc własnych providerów, umieszczać ja na własnych zasobach, a do tego używać mnóstwo gotowych modułów lub napisać własne. Prognozuję dalszy wzrost użycia Terraform i większą ilość providerów. Nie wyobrażam sobie poważnego środowiska, które w roku 2022 wyklikuje się z GUI zamiast z kodu.\nEverything as Code Idąc za Kubernetes i Terraform, łatwo przewidzieć dokąd zmierzamy - to koncepcja Everything as Code. Nie tylko Infrastructure as Code, ale wszystko będzie opisywane kodem. To będzie przekładać się na potrzebę jeszcze większej automatyzacji. Będzie jeszcze więcej operatorów dla platform opartych o Kubernetes, będzie coraz więcej usług u dostawców chmur publicznych, więcej providerów Terraform umożliwi ich obsługę, a aplikacje będą w całości dostarczane przez pipeline’y CI/CD. Coraz więcej wiedzy i praktyk dotyczących infrastruktury będzie ukryta w oprogramowaniu operowanym przez API. Będzie tu królować Go jako język najłatwiej integrujący się z platformami (m.in. dzięki natywnym klientom dla Kubernetes, Terraform, różnych platform chmurowych i serverless) i świetnie działającymi w kontenerach (statyczne binaria i jednoplikowe obrazy kontenerów). W dużej mierze to się już dzieje w nowoczesnych organizacjach, a reszta po prostu będzie nadganiać.\nBezpieczeństwo priorytetem Chyba niewiele poważnych organizacji rzuca się na nowe technologie bez przeanalizowania tego pod względem wpływu na bezpieczeństwo. Być może dlatego tak wiele z nich boi się zmian i wprowadzania kontenerów czy Kubernetesa. Wydaje się im, że lepiej jest pozostać przy czymś znanym. To jeszcze można zrozumieć jeśli dana technologia jest odpowiednio łatana, ale coraz częściej producenci oprogramowania życzą sobie taczki pieniędzy za utrzymywanie przy życiu takich produktów. Bezpieczne platformy można budować zarówno korzystając z maszyn wirtualnych, chmur publicznych czy prywatnych, ale coraz częściej to właśnie Kubernetes odpala skonteneryzowane aplikacje. I niezależnie od wyboru zawsze pozostaje temat bezpieczeństwa. W roku 2022 jeszcze częściej będzie słychać pojęcie DevSecOps, czyli zagnieżdżenia mechanizmów kontroli bezpieczeństwa na jak najwcześniejszym etapie (czyli Shift Left). Nie wyobrażam sobie, aby bezpieczeństwo było procesem opisanym w dokumentach, a nie w kodzie. Narzędzia takie jak OPA, Kyverno czy Vault będą jeszcze bardziej potrzebne.\nPraca zdalna (lub przynajmniej hybrydowa) Ostatnie dwa lata pokazały, że praca zdalna jest możliwa i nie wpływa ona negatywnie na efektywność organizacji. To świetna wiadomość dla tych spędzających wiele godzin na dojazdach i mieszkających z dala od zgiełku miast. Będą mogli oni teraz swobodniej wybierać pracodawców i uczestniczyć w ciekawych projektach bez konieczności przeprowadzki do innego miasta lub kraju. To już wprowadziło niezłe zamieszanie na rynku pracy otwierając możliwości dla DevOpsów i nie tylko. Dla tych jak ja, którzy czasem potrzebują kontaktu na żywo, pozostanie model hybrydowy. Ja osobiście wierzę, że jest on nam potrzebny do lepszej komunikacji. I mogą to być spotkania raz na tydzień lub nawet raz na miesiąc. Moje doświadczenie pokazuje mi, że lepiej mi się rozmawia na żywo - wyraźniej odbieram sygnały niewerbalne, mimikę twarzy rozmówcy co pozwala mi lepiej zrozumieć drugą stronę. Z drugiej strony z czasem myślę, że szczęście w tym pandemicznym nieszczęściu polega na tym, że COVID przyszedł w czasach, gdy technologia zmniejsza jego wpływ na nasze życie.\nWiększe zapotrzebowanie na DevOps To jeszcze a propos pracy zdalnej i pandemii. Otóż okazało się, że ci którzy byli przygotowani na pracę zdalną nie tylko w firmach, ale urzędach, radzą sobie lepiej. Istnieją jednak kraje i organizacje, gdzie postęp nie był wystarczająco szybki. Pandemia zaś pokazała braki w przygotowaniu urzędów i organizacji, które teraz muszą szybko te niedostatki transformacji cyfrowej nadrobić. I nawet jak są już gotowe rozwiązania, oprogramowanie wytworzone i używane przez podobne jednostki, to wciąż trzeba to wszystko ze sobą spiąć. I tu wracamy do roli DevOps w tym wszystkim. To dzięki zdolnym inżynierom potrafiącym wykorzystać chmurę, kontenery, różnego rodzaju API i tradycyjną infrastrukturę (często chmura jest po prostu poza zasięgiem), taka przyspieszona transformacja ma szanse na powodzenie. Zatem głowa do góry (ewentualnie do książek i edukacji), a ręce na klawiatury - czas zakasać rękawy i wprowadzić pozostałych w XXI wiek!\nCloudowski urośnie I to nie tylko przez zbyt dużą ilość sernika, który pochłonąłem w ostatnie święta! Mówię tutaj o moich ambitnych planach, które sobie postawiłem na rok 2022. Nie mogę zdradzić ich wszystkich, ale uchylę przed Tobą rąbka tajemnicy. Oto co się wydarzy u mnie:\nZacznę publikować mój własny podcast o DevOps - pierwsze odcinki już wkrótce! Odsłonię kulisy mojej pracy - założyłem konto na instagramie! Będę tworzył więcej treści po polsku - więcej artykułów i więcej ciekawych filmów na YouTube Będę nagrywał i prowadził kolejne warsztaty z tematyki DevOps, Kubernetes, Terraform i Cloud ⎈ Wydam odświeżoną wersję mojego kursu “Kubernetes po polsku” Poprowadzę tradycyjne szkolenia, aby pomóc innym zacząć efektywniej używać narzędzi i procesów DevOps (na tą chwilę mam już zajęte kilka pierwszych miesięcy) To tylko wycinek tego co mam w planach. Zapowiada się bardzo pracowity rok.\nA czy ty już masz spisane swoje plany? Z mojego doświadczenia podpowiem, że tylko te spisane ręcznie mają większe szanse realizacji. I najlepiej noś ze sobą tą listę lub powieś w widocznym miejscu. Nic nie działa tak dobrze jak koncentracja na rzeczach dla Ciebie ważnych.\n","tags":["devops","devsecops","kubernetes","terraform"],"title":"Co przyniesie rok 2022 dla DevOps"},{"categories":["articles"],"date":"April 8, 2021","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/a-recipe-for-a-bespoke-on-prem-kubernetes-cluster/","section":"articles","summary":"So you want to build yourself a Kubernetes cluster? You have your reasons. Some may want to utilize the hardware they own, some may not fully trust these fancy cloud services or just simply want to have a choice and build themselves a hybrid solution. There are a couple of products available that I’ve reviewed, but you’ve decided to build a platform from scratch. And again, there are a myriad of reasons why it might be a good idea and also many that would convince you it’s not worth your precious time. In this article, I will focus on providing a list of things to consider when starting a project building a Kubernetes-based platform using only the most popular open source components.\nTarget groups Before we jump into the technicalities, I want to describe three target groups that are referred to in the below sections.\n(SUP) - very small companies or the ones with basic needs; their focus is on using basic Kubernetes API and facilitating services around it Medium businesses (MBU) - medium companies which want to leverage Kubernetes to boost their growth and innovation; their focus is on building a scalable platform that is also easy to maintain and extend Enterprises (ENT) - big companies with even bigger needs, scale, many policies, and regulations; they are the most demanding and are focused on repeatability, security, and scalability (in terms of the growing number of developers and teams working on their platform) All these groups have different needs and thus they should build their platform in a slightly different way with different solutions applied to particular areas. I will refer to them using their abbreviations or as ALL when referring to all of them.\nInstallation When to apply: Mandatory for ALL Purpose: To have a robust and automated way of management your cluster(s)\nWhen deciding on installing Kubernetes without using any available distribution you have a fairly limited choice of installers. You can try using kubeadm directly or use more generic kubespray. The latter one will help you not only install, but also maintain your cluster (upgrades, node replacement, cluster configuration management). Both of these are universal and are unaware of how cluster nodes are provisioned. If you wish to use an automated solution that would also handle provisioning cluster nodes then Metal3 could be something you might want to try. It’s still in the alpha stage, but it looks promising.\nIf you want a better and more cloud-native way of managing your clusters that would enable easy scaling then you may want to try ClusterAPI project. It supports multiple cloud providers, but it can be used on on-prem environments with the aforementioned Metal3, vSphere, or OpenStack.\nOne more thing worth noting here: the operating system used by cluster nodes. Since the future of CentOS seems unclear, Ubuntu becomes the main building block for bespoke Kubernetes clusters. Some may want to choose a slim alternative that has replaced CoreOS - Flatcar Linux.\nCluster autoscaler When to apply: Highly recommended for ENT, optional for others Purpose: Scale up and down automatically your platform\nIf you choose ClusterAPI or your cluster uses some API in another way to manage cluster nodes (e.g. vSphere, OpenStack, etc.) then you should also use the cluster autoscaler component. It is almost a mandatory feature for ENT but it can also be useful for MBU organizations. By forcing nodes to be ephemeral entities that can be easily replaced/removed/added, you decrease the maintenance costs.\nNetwork CNI plugin When to apply: Mandatory for ALL Purpose: Connect containers with optional additional features such as encryption\nThe networking plugin is one of the decisions that need to be taken prudently, as it cannot be easily changed afterward. To make things brief I would shorten the list to two plugins - Calico or Cilium. Calico is older and maybe a little bit more mature, but Cilium looks very promising and utilizes Linux Kernel BPF. For a more detailed comparison I would suggest reading this review of multiple plugins. Choose wisely and avoid CNI without NetworkPolicy support - having a Kubernetes cluster without the possibility to implement firewall rules is a bad idea. Both Calico and Cilium support encryption, which is a nice thing to have, but Cilium is able to encrypt all the traffic (Calico encrypts only pod-to-pod).\nIngress controller When to apply: Mandatory for ALL Purpose: Provide an easy and flexible way to expose web applications with optional advanced features\nIngress is a component that can be easily swapped out when the cluster is running. Actually, you can have multiple Ingress controllers by leveraging IngressClass introduced in Kubernetes 1.18. A comprehensive comparison can be found here, but I would limit it to a select few controllers depending on your needs.\nFor those looking for compatibility with other Kubernetes clusters (e.g. hybrid solution), I would suggest starting with the most mature and battle-tested controller - nginx ingress controller. The reason is simple - you need only basic features described in Ingress API that have to be implemented by every Ingress controller. That should cover 90% of cases, especially for SUP group.\nIf more features are required (such as sophisticated http routing, authentication, authorization, etc.) then the following options are the most promising:\nContour - it’s the only CNCF project that is in the Incubating maturity level group. And it’s based on Envoy which is the most flexible proxy available out there. Ambassador - has nice features, but many of them are available in the paid version. And yes - it also uses Envoy. HAproxy from HAproxytech - for those who are familiar with HAproxy and want to leverage it to provide a robust Ingress controller Traefik - they have an awesome logo and if you’ve been using it for some Docker load-balancing then you may find it really useful for Ingress as well Monitoring When to apply: Mandatory for ALL (unless an existing monitoring solution compatible with Kubernetes exists) Purpose: Provide insights on cluster state for operations teams\nThere is one king here - just use Prometheus. Probably the best approach would be using an operator that would install Grafana alongside some predefined dashboards.\nLogging When to apply: Mandatory for ALL (unless an existing central logging solution is already is) Purpose: Provide insights on cluster state for operations teams\nIt’s quite similar to monitoring - the majority of solutions are based on Elasticsearch, Fluentd and Kibana. This suite has broad community support and many problems have been solved and described thoroughly in many posts on the web. ALL should have a logging solution for their platforms and the easiest way to implement it is to use an operator like this one or a Helm Chart like this based on Open Distro (it’s an equivalent of Elasticsearch with more lenient/open source license).\nTracing When to apply: Optional for ALL Purpose: Provide insights and additional metrics useful for application troubleshooting and performance tuning\nTracing is a feature that will be highly coveted in really big and complex environments. That’s why ENT organizations should adopt it and the best way is to implement it using Jaeger. It’s one of graduated CNCF projects which only makes it more appealing, as it’s been proven to be not only highly popular but also has a healthy community around it. Implementation requires some work on the application’s part, but the service itself can be easily installed and maintained using this operator.\nBackup When to apply: Mandatory for ENT, optional for the rest Purpose: Apply the *“Redundancy is not a backup solution” approach\nALL should remember that redundancy is not a backup solution. Although with a properly implemented GitOps solution, where each change of the cluster state goes through a dedicated git repository, the disaster recovery can be simplified, in many cases, it’s not enough. For those who plan to use persistent storage, I would recommend implementing Velero.\nStorage When to apply: For ALL if stateful applications are planned to be used Purpose: Provide flexible storage for stateful applications and services\nThe easiest use case of Kubernetes is stateless applications that don’t need any storage for keeping their state. Most microservices use some external service (such as databases) that can be deployed outside of a cluster. If persistent storage is required it can still be provided using already existing solutions from outside a Kubernetes cluster. There are some drawbacks (i.e. the need to provision persistent volumes manually, less reliability and flexibility) in many of them and that’s why keeping storage inside a cluster can be a viable and efficient alternative. I would limit the choices for such storage to the following projects:\nRook OpenEBS Rook is the most popular and when properly implemented (e.g. deployed on a dedicated cluster or on a dedicated node pool with monitoring, alerting, etc.) can be a great way of providing storage for any kind of workloads, including even production databases (although this topic is still controversial and we all need time to accustom to this way of running them).\nSecurity This part is crucial for organizations that are focused on providing secure platforms for the most sensitive parts of their systems.\nNon-root containers When to apply: Mandatory for ENT and probably MBU Purpose: Decrease the risk of potential exploiting of vulnerabilities found in applications or the operating system they use\nOpenShift made a very brave and good decision by providing a default setting that forbids running containers under the root account. I think this setting should be also implemented for ALL organizations that want to increase the level of workloads running on their Kubernetes clusters. It is quite easy to achieve by implementing PodSecurityPolicy admission controller and applying proper rules. It’s not even an external project, but it’s a low-hanging fruit that should be mandatory to implement for larger organizations. This, however, brings consequences in what images would be used on a platform. Most ”official” images available on Docker Hub run as root, but I see how it changes, and hopefully, it will change in the future.\nEnforcing policies with OpenPolicyAgent When to apply: Mandatory for ENT, optional for others Purpose: Enforce security and internal policies\nMany organizations produce tons of security policies written down in some documents. They are often enforced by processes and audited yearly or rarely. In many cases, they aren’t adjusted to the real world and were created mostly to meet some requirements instead of protecting and ensuring best security practices are in place. It’s time to start enforcing these policies on the API level and that’s where OpenPolicyAgent comes to play. Probably it’s not required for small organizations, but it’s definitely mandatory for larger ones where risks are much higher. In such organizations properly configured rules that may:\nprevent pulling images from untrusted container registries prevent pulling images outside of a list of allowed container images enforce the use of specific labels describing a project and its owner enforce the applying of best practices that may have an impact on the platform reliability (e.g. defining resources and limits, use of liveness and readiness probes) granularly restrict the use of the platform’s API (Kubernetes RBAC can’t be used to specify exceptions) Authentication When to apply: Mandatory for ALL, for some SUP it may be optional Purpose: Provide a way for user to authenticate and authorize to the platform\nThis is actually a mandatory component for all organizations. One thing that may surprise many is how Kubernetes treats authentication and how it relies on external sources for providing information on users. This means almost unlimited flexibility and at the same time adds even more work and requires a few decisions to be made. To make it short - you probably want something like DEX that acts as a proxy to your real Identity Provider (DEX supports many of these, including LDAP, SAML 2.0, and most popular OIDC providers). To make it easier to use you can add Gangway. It’s a pair of projects that are often used together.\nYou may find Keycloak as an alternative that is more powerful, but at the same time is also more complex and difficult to configure.\nBetter secret management When to apply: Mandatory for ENT Purpose: Provide a better and more secure way of handling confidential information on the platform\nFor smaller projects and organizations encrypting Secrets in a repo where they are stored should be sufficient. Tools such as git-crypt , git-secret or SOPS do a great job in securing these objects. I recommend especially the last one - SOPS is very universal and combined with GPG can be used to create a very robust solution. For larger organizations, I would recommend implementing HashiCorp Vault which can be easily integrated with any Kubernetes cluster. It requires a bit of work and thus the use of it for small clusters with few applications seems to make no sense. For those who have dozens or even hundreds of credentials or other confidential data to store Vault can make their life easier. Auditing, built-in versioning, seamless integration, and what is the killer feature - dynamic secrets. By implementing access to external services (i.e. various cloud providers, LDAP, RabbitMQ, ssh and database servers) using credentials created on-demand with a short lifetime, you set a different level of security for your platform.\nSecurity audits When to apply: Mandatory for ENT and MBU Purpose: Get more information on potential security breaches\nWhen handling a big environment, especially one that needs to be compliant with some security standards, providing a way to report suspicious activity is one of the most important requirements. Setting auditing for Kubernetes is quite easy and it can even be enhanced by generating more granular information on specific events generated not by API components, but by containers running on a cluster. The project that brings these additional features is Falco. It’s really amazing how powerful this tool is - it uses the Linux kernel’s internal API to trace all activity of a container such as access to files, sending or receiving network traffic, access to Kubernetes API, and many, many more. The built-in rules already provide some useful information, but they need to be adjusted for specific needs to get rid of false positives and triggers when unusual activities are discovered on the cluster.\nContainer images security scanning When to apply: Mandatory for ALL Purpose: Don’t allow to run containers with critical vulnerabilities found\nThe platform security mostly comes down to vulnerabilities in the containers running on it. That’s why it is so important to ensure that the images used to run these containers are scanned against most critical vulnerabilities. This can be achieved in two ways - one is by scanning the images on a container registry and the other is by including an additional step in the CI/CD pipeline used for the deployment.\nIt’s worth considering keeping container images outside of the cluster and relying on existing container registries such as Docker Hub, Amazon ECR, Google GCR or Azure ACR. Yes - even when building an on-prem environment sometimes is just easier to use a service from a public cloud provider. It is especially beneficial for smaller organizations that don’t want to invest too much time in building a container registry and at the same time they want to provide a proper level of security and reliability.\nThere is one major player in the on-prem container registries market that should be considered when building such a service. It’s Harbor which has plenty of features, including security scanning, mirroring of other registries, and replication that allows adding more nines to its availability SLO. Harbor has a built-in Trivy scanner that works pretty well and is able to find vulnerabilities on the operating system level and also in the application packages.\nTrivy can also be used as a standalone tool in a CI/CD pipeline to scan the container image built by one of the stages. This one-line command might protect you from serious troubles as many can be surprised by the number of critical vulnerabilities that exist even in the official docker images.\nExtra addons On top of basic Kubernetes features there are some interesting addons that extend Kubernetes basic features.\nUser-friendly interface When to apply: Mandatory for ENT and MBU Purpose: Allow less experienced users to use the platform\nWho doesn’t like a nice GUI that helps to get a quick overview of what’s going on with your cluster and applications running on it? Even I crave such interfaces and I spend most of my time in my command line or with my editor. These interfaces when designed properly can speed up the process of administration and just make the work with the Kubernetes environment much more pleasant. The ”official” Kubernetes dashboard project is very basic and it’s not the tool that I would recommend for beginners, as it may actually scare people off instead of drawing them to Kubernetes. I still believe that OpenShift’s web console is one of the best, but unfortunately it cannot be easily installed with any Kubernetes cluster. If it was possible then it would definitely be my first choice. Octant looks like an interesting project that is extensible and there are already useful plugins available (e.g. Aqua Security Starboard). It’s rather a platform than a simple web console, as it actually doesn’t run inside a cluster, but on a workstation. The other contestant in the UI category is Lens. It’s also a standalone application. It works pretty well and shows nice graphs when there’s a prometheus installed on the cluster.\nService mesh When to apply: Optional for ALL Purpose: Enable more advanced traffic management, more security and flexibility for the applications running on the platform\nBefore any project name appears here there’s a fundamental question that needs to be asked here - do you really need a service mesh for your applications? I wouldn’t recommend it for organizations which just start their journey with cloud native workloads. Having an additional layer can make non-so-trivial management of containers even more complex and difficult. Maybe you want to use service mesh only to encrypt traffic? Consider a proper CNI plugin that would bring this feature transparently. Maybe advanced deployment seems like a good idea, but did you know that even basic Nginx Ingress controller supports canary releases? Introduce a service mesh only then when you really need a specific feature (e.g. multi-cluster communication, traffic policy, circuit breakers, etc.). Most readers would probably be better off without service mesh and for those prepared for the additional effort related to increased complexity the choice is limited to few solutions. The first and most obvious one is Istio. The other that I can recommend is Consul Connect from HashiCorp. The former is also the most popular one and is often provided as an add-on in the Kubernetes services in the cloud. The latter one seems to be much simpler, but also is easier to use. It’s also a part of Consul and together they enable creation and management of multi-cluster environments.\nExternal dns When to apply: Optional for ALL, recommended for dynamic environments Purpose: Decrease the operational work involved with managing new DNS entries\nSmaller environments will probably not need many dns records for the external access via load balancer or ingress services. For larger and more dynamic ones having a dedicated service managing these dns records may save a lot of time. This service is external-dns and can be configured to manage dns records on most dns services available in the cloud and also on traditional dns servers such as bind. This addon works best with the next one which adds TLS certificates to your web applications.\nCert-manager When to apply: Optional for ALL, recommended for dynamic environments Purpose: Get trusted SSL certificates for free!\nDo you still want to pay for your SSL/TLS certificates? Thanks to Let’s Encrypt you don’t need to. But this is just one of the Let’s Encrypt’s features. Use of Let’s Encrypt has been growing rapidly over the past few years. Tand the reason why is that it’s one of the things that should be at least considered as a part of the modern Kubernetes platform is how easy it is to automate. There’s a dedicated operator called cert-manager that makes the whole process of requesting and refreshing certificates very quick and transparent to applications. Having trusted certificates saves a lot of time and trouble for those who manage many web services exposed externally, including test environments. Just ask anyone who had to inject custom certificate authority keys to dozens of places to make all the components talk to each other without any additional effort. And cert-manager can be used for internal Kubernetes components as well. It’s one of my favourite addons and I hope many will appreciate it as much as I do.\nAdditional cluster metrics When to apply: Mandatory for ALL Purpose: Get more insights and enable autoscaling\nThere are two additional components that should be installed on clusters used in production. They are metrics-server and kube-state-metrics. The first is required for the internal autoscaler (HorizontalPodAutoscaler) to work, as metrics-server exposes metrics gathered from various cluster components. I can’t imagine working with a production cluster that lack of these features and all the events that should be a part of standard security review processes and alerting systems.\nGitOps management When to apply: Optional for ALL, recommended for ENT Purpose: Decrease the operational work involved with cluster management\nIt is not that popular yet, but cluster and environment management is going to be an important topic, especially for larger organizations where there are dozens of clusters, namespaces and hundreds of developers working on them. Management techniques involving git repositories as a source of truth are known as GitOps and they leverage the declarative nature of Kubernetes. It looks like ArgoCD has become a major player in this area and installing it on the cluster may bring many benefits for teams responsible for maintenance, but also for security of the whole platform.\nConclusion The aforementioned projects do not even begin to exhaust the subject of the solutions available for Kubernetes. This list merely shows how many possibilities are out there, how rich the Kubernetes ecosystem is, and finally how quickly it evolves. For some it may be also surprising how standard Kubernetes lacks some features required for running production workloads. Even the multiple versions of Kubernetes-as-a-Service available on major cloud platforms are missing most of these features, let alone the clusters that are built from scratch for on-prem environments. It shows how difficult this process of building a bespoke Kubernetes platform can become, but at the same time those who will manage to put it all together can be assured that their creation will bring their organization to the next level of automation, reliability, security and flexibility. For the rest there’s another and easier path - using a Kubernetes-based product that has most of these features built-in.\n","tags":["containers","kubernetes","onprem"],"title":"A recipe for a bespoke on-prem Kubernetes cluster"},{"categories":["articles"],"date":"January 30, 2021","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/which-kubernetes-distribution-to-choose-for-on-prem-environments/","section":"articles","summary":"Most people think that Kubernetes was designed to bring more features and more abstraction layers to cloud environments. Well, I think the biggest benefits can be achieved in on-premise environments, because of the big gap between those environments and the ones that can be easily created in the cloud. This opens up many excellent opportunities for organizations which for some reasons choose to stay outside of the public cloud. In order to leverage Kubernetes using on-premise hardware, one of the biggest decisions that needs to be made which software platform to use for Kubernetes. According to the official listing of available Kubernetes distributions, there are dozens of options available. If you look closely at them, however, there are only a few viable ones, as many of them are either inactive or have been merged with other projects (e.g. Pivotal Kubernetes Service merged with VMware Tanzu). I expect that 3-5 of these distributions will eventually prevail in the next 2 years and they will target their own niche market segments. Let’s have a look at those that have stayed in the game and can be used as a foundation for a highly automated on-premise platform.\n1. OpenShift I’ll start with the obvious and probably the best choice there is - OpenShift Container Platform. I’ve written about this product many times and still there’s no better Kubernetes distribution available on the market that is so rich in features. This also comes with its biggest disadvantage - the price that for some is just too high. OpenShift is Red Hat’s flagship product that is targeted at enterprises. Of course they sell it to medium or even small companies, but the main target group is big enterprises with a big budget. It has also become a platform for Red Hat’s other products or other vendors’ services that are easily installable and available at https://www.operatorhub.io/. OpenShift can be installed in the cloud, but it’s on-premise environments is where it shows its most powerful features. Almost every piece of it is highly automated and this enables easy maintenance of clusters (installation, upgrades and scaling), rapid deployment of supplementary services (databases, service mesh) and platform configuration. There is no other distribution that has achieved that level of automation. OpenShift is also the most complete solution which includes integrated logging, monitoring and CI/CD (although they are still working on switching from Jenkins to Tekton engine which is not that feature-rich yet).\nWhen to choose OpenShift If you have a big budget - money can’t bring happiness, but it can buy you the best Kubernetes distribution, so why hesitate? If you want to have the easiest and smoothest experience with Kubernetes - a user-friendly web console that is second to none and comprehensive documentation. You don’t plan to scale rapidly but you need a bulletproof solution - OpenShift can be great for even small environments and as long as they won’t grow it can be financially reasonable Your organization has few DevOps/Ops people - OpenShift is less demanding from a maintenance perspective and may help to overcome problems with finding highly skilled Kubernetes and infrastructure experts The systems that your organization builds are complex - in cases where the development and deployment processes require a lot of additional services, there’s no better way to create and maintain clusters on on-premise environments than by using operators (and buying additional support for them if needed) If you need support (?) - I’ve put it here just for the sake of providing some reasonable justification for the high price of an OpenShift subscription, but unfortunately many customers are not satisfied with the level of product support and thus it’s not the biggest advantage here When to avoid OpenShift All you need is Kubernetes API - maybe all these fancy features are just superfluous and just plain Kubernetes distribution is enough, provided that you have a team of skilled people that could build and maintain it If your budget is tight - that’s obvious, but many believe they can somehow overcome the high price of OpenShift by efficiently bin packing their workloads on smaller clusters or get a real bargain when ordering their subscriptions (I guess it’s possible, but only for really big orders for hundreds of nodes) Your organization is an avid supporter of open source projects and avoids any potential vendor lock-ins - although OpenShift includes Kubernetes and can be fully compatible with other Kubernetes distributions, there are some areas where a potential vendor lock-in can occur (e.g. reliance on builtin operators and their APIs) 2. OKD Back in the day Red Hat used upstream-downstream strategy for product development where open source upstream projects were free to use and their downstream, commercial products were heavily dependent on their upstreams and built on top of them. That has changed with OpenShift 4 where its open source equivalent - OKD - was released months after OpenShift had been redesigned, with help from guys from CoreOS (Red Hat acquired CoreOS in 2018). So OKD is an open source version of OpenShift and it’s free. It’s a similar strategy that Red Hat has been using for years - to attract people and accustom them to the free (upstream) versions and also give them a very similar experience to their paid products. The only difference is of course lack of support and few features that are available in OpenShift only. That’s what the key factors to consider are when deciding on a Kubernetes platform - does your organization need support or will it get by without it? Things got a little bit more complicated after Red Hat (who own CentOS project) has announced that CentOS 8 will cease to exist in the form that has been known for years. CentOS is widely used by many companies as a free version of RHEL (Red Hat Enterprise Linux) and it looks like it has changed and we don’t know what IBM will do with OKD (I suspect it was their business decision to pull the plug). There’s a risk that OKD will also no longer be developed, or at least it will not resemble OpenShift like it does now. As for now being still very similar to OpenShift, OKD can be also considered as one of the best Kubernetes platforms to use for on-premise installations.\nWhen to choose OKD You don’t care about Red Hat addons, but still need a highly automated platform - OKD can still brings your environment to a completely different level by leveraging operators, builtin services (i.e. logging, monitoring) You don’t need support, because you have really smart people with Kubernetes skills - either you pay Red Hat for its support or build an internal team that would act as 1st, 2nd and 3rd line of support (not mentioning the vast resources available on the web) You plan to run internal workloads only without exposing them outside - Red Hat brags about providing curated list of container images while OKD relies on community’s work on providing security patches and this causes some delays; for some this can be an acceptable risk, especially if the platform is used internally You need a Kubernetes distribution that is user-friendly - web console in OKD is almost identical to the one in OpenShift which I already described before as second to none; it often helps less experienced users to use it and even more experienced ones can use it to perform daily tasks even faster by leveraging all the information gathered in a concise form You want to decrease costs of OpenShift and use it for testing environments only - this idea seems to be reasonable from the economic point of view and if planned and executed well it makes sense; there are some caveats though (e.g. it is against Red Hat license to use most of their container images) When to avoid OKD Plain Kubernetes is all you need - with all these features comes complexity that may be just not what your organization needs and you’d be better off with some simpler Kubernetes distribution You expect quick fixes and patches - don’t get me wrong, it looks like they are delivered, but it’s not guaranteed and relies solely on community (e.g. for OpenShift Origin 3, a predecessor of OKD, some container images used internally by the platform haven’t been updated for months whereas OpenShift provided updates fairly quickly) You need a stable and predictable platform - nobody expected CentOS 8 would no longer be an equivalent to RHEL and so similar decisions of IBM executives can affect OKD and there’s a risk that sometime in the future all OKD users would have no choice but to migrate to some other solution 3. Rancher After Rancher had been accquired by SUSE, a new chapter opened for this niche player on the market. Although SUSE already had their own Kubernetes solution, it’s likely that they will only have a single offering of that type and it’s going to be Rancher. Basically, Rancher offers an easy management of multiple Kubernetes clusters that can be provisioned manually and imported into the Cluster Manager management panel or provisioned by Rancher using its own Kubernetes distribution. They call it RKE - Rancher Kubernetes Engine and it can be installed on most major cloud providers, but also on vSphere. Managing multiple clusters using Rancher is very easy and combining it with plenty of authentication options makes it a really compelling solution for those who plan to manage hybrid, multi-cluster, or even multi-cloud environments. I think that Rancher has initiated many interesting projects, including K3S (simpler Kubernetes control plane targeted for edge computing) , RKE (the aforementioned Kubernetes distribution), and Longhorn (distributed storage). You can see they are in the middle of an intensive development cycle - even by looking at the Rancher’s inconsistent UI which is divided into two: Cluster Manager with a fresh look, decent list of options, and Cluster Explorer that is less pleasant, but offers more insights. Let’s hope they will continue improving Rancher and its RKE to be even more usable so that it would become an even more compelling Kubernetes platform for on-premise environments.\nWhen to choose Rancher If you already have VMware vSphere - Rancher makes it very easy to spawn new on-premise clusters by leveraging vSphere API If you plan to maintain many clusters (all on-premise, hybrid or multi-cloud) - it’s just easier to manage them from a single place where you log in using unified credentials (it’s very easy to set up authentication against various services) You focus on platform maintenance more than on features supporting development - with nice integrated backup solution, CIS benchmark engine and only few developer-focused solution (I think their CI/CD solution was put there just for the sake of marketing purposes - it’s barely usable) it’s just more appealing to infrastructure teams If you really need paid support for your Kubernetes environment - Rancher provides support for its product, including their own Kubernetes distribution (RKE) as well as for custom installations; When it comes to price it’s a mystery that will be revealed when you contact Sales You need a browser-optimized access to your environment - with builtin shell it’s very easy to access cluster resources without configuring anything on a local machine When to avoid Rancher You don’t care about fancy features - although there are significantly less features in Rancher than in OpenShift or OKD, it is still more than just a nice UI and some may find it redundant and can get by without them You’re interested in more mature products - it looks like Rancher has been in an active development over the past few months and probably it is going to be redesigned and some point, just like it happened with OpenShift (version 3 and 4 are very different) You don’t plan or need to use multiple clusters - maybe one is enough? 4. VMware Tanzu The last contender is Tanzu from the biggest on-premise virtualization software vendor. When they announced project Pacific I knew it was going to be huge. And it is. Tanzu is a set of products that leverage Kubernetes and integrate them with vSphere. The product that manages Kubernetes clusters is called Tanzu Kubernetes Grid (TKG) and it’s just the beginning of Tanzu offering. There’s Tanzu Mission Control for managing multiple clusters, Tanzu Observability for.. observability, Tanzu Service Mesh for.. yes, it’s their service mesh, and many more. For anyone familiar with enterprise offering it may resemble any other product suite from a big giant like IBM, Oracle and so on. Let’s be honest here - Tanzu is not for anyone that is interested in “some” Kubernetes, it’s for enterprises accustomed to enterprise products and everything that comes with it (i.e. sales, support, software that can be downloaded only for authorized users, etc.). And it’s especially designed for those whose infrastructure is based on the VMware ecosystem - it’s a perfect addition that meets requirements of development teams within an organization, but also addresses operations teams concerts with the same tools that’s been known for over a decade now. When it comes to features they are pretty standard - easy authentication, cluster scaling, build services based on buildpacks, networking integrated with VMware NSX, storage integrated with vSphere - wait, it’s starting to sound like a feature list of another vSphere addon. I guess it is an addon. For those looking for fancy features I suggest waiting a bit more for VMware to come up with new Tanzu products (or for a new acquisition of another company from cloud native world like they did with Bitnami).\nWhen to choose Tanzu When your company already uses VMware vSphere - just contact your VMware sales guy who will prepare you an offer and the team that takes care of your infrastructure will do the rest If you don’t plan to deploy anything outside of your own infrastructure - although VMware tries to be a hybrid provider by enabling integration with AWS or GCP, it will stay focused on on-premise market where it’s undeniably the leader If you wish to use multiple clusters - Tanzu enables easy creation of Kubernetes clusters that can be assigned to development teams If you need support - it’s an enterprise product with enterprise support When to avoid Tanzu If you don’t have already vSphere in your organization - you need vSphere and its ecosystem, that Tanzu is a part of, to start working with VMware’s Kubernetes services; otherwise it will cost you a lot more time and resources to install it just to leverage them When you need more features integrated with the platform - although Tanzu provides interesting features (my favourite is Tanzu Build Service) it still lacks of some distinguished ones (although they provide some for you to install on your own from Solutions Hub) that would make it more appealing Conclusion I have chosen these four solutions for Kubernetes on-premise platform because I believe they provide a real alternative to custom-built clusters. These products make it easier to build and maintain production clusters, but also in many cases help to speed up the development process and provide insights for the deployment process as well. So here’s what I would do if I were to choose one:\nif I had a big budget I would go with OpenShift, as it’s just the best if I had a big budget and already existing VMware vSphere infrastructure I would consider Tanzu if I had skilled Kubernetes people in my organization and I wanted to have an easy way to manage my clusters (provisioned manually) without vSphere I would choose Rancher (and optionally I would buy a support for those clusters when going to prod) if I had skilled Kubernetes people in my organization and I would like to use these fancy OpenShift features I would go with OKD, as it’s the best alternative to custom-built Kubernetes cluster That’s not all. Of course you can build your own Kubernetes cluster and it’s a path that is chosen by many organizations. There are many caveats and conditions that need to be met (e.g. scale of such endeavour, type of workloads to be deployed on it) for this to succeed. But that’s a different story which I hope to cover in some other article.\n","tags":["containers","kubernetes","okd","onprem","openshift","rancher","tanzu"],"title":"Which Kubernetes distribution to choose for on-prem environments?"},{"categories":["pl"],"date":"January 9, 2021","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/pl/bezbledni/","section":"pl","summary":"Mówiono nam, że tacy właśnie mamy być, aby odnieść sukces. Bezbłędni. Od początku w szkole i aż do pracy zawodowej. Ten artykuł poświęcam właśnie największej przeszkodzie stojącej na drodze do innowacji i sukcesu naszych firm oraz nas - niezależnie czy jesteśmy pracownikami, menedżerami, właścicielami firm czy też dopiero stawiamy pierwsze zawodowe kroki.\nGeneza Obserwując nasze społeczeństwo i pamiętając jak wyglądało to jak byłem dzieckiem, później w szkole i w dalszych etapach mojego życia, mam wrażenie, że to nastawienie na błędy jest bardzo mocno zakorzenione w naszym społeczeństwie (albo przynajmniej w jego sporej części). Może to tylko moje doświadczenia, ale przeglądając internet trafiłem na ciekawy zapis jedynego źródła informacji jakie mieli nasi rodzice, dziadkowie w latach komunizmu - Dziennika Telewizyjnego (odpowiednik dzisiejszych Wiadomości). Polecam każdemu sprawdzić samodzielnie jak już wówczas społeczeństwo było nastawione na szukanie błędów. Komiczne są sytuacje, gdzie ze względu na przerwane łańcuchy dostaw i niedomagającą gospodarkę, redaktor prowadzący zaciekle szuka winy za brak chleba w sklepie u… kierowniczki tegoż. Oczywiście sytuacje takie zdarzają się również dzisiaj, ale przyzwyczajenie do szukania win zamiast rozwiązań jest z pewnością najłatwiejsze i najwygodniejsze, ale niezwykle ograniczające i nawet wręcz głupie jak się choć chwilę zatrzymać i zastanowić.\nDlaczego Wizją takiego świata łatwo jest zarazić swoje najbliższe otoczenie. Jest ona na tyle kusząca, że zdejmuje z nas odpowiedzialność za podejmowanie ryzyka i ciężkiej pracy. Niesie ona też poczucie ulgi, gdy to komuś się nie udało i to jego “złapano” go na błędzie. To wspaniała ucieczka przed tą ocena i narażaniem się na śmieszność, krytykę i porażkę, a tak można w zaciszu swojej strefy komfortu usiąść w loży szyderców z innymi o podobnych lękach. Byłem tam. Lubiłem moją lożę i mój wyszukany sarkazm, który jest potężną bronią i tarczą zarazem. Pomaga w utwierdzaniu się o słuszności niewychodzenia i niekonfrontowania się z brutalną niekiedy rzeczywistością, szczególnie gdy rzeczywistość ta jest złożona właśnie z innych wytykających nasze błędy i czerpiących z tego niemałą satysfakcję.\nKonsekwencje O jak wygodnie jest być w miejscu, gdzie jedynym wysiłkiem jest szukanie wad i błędów u innych! A to, bądźmy tutaj szczerzy, jest dość łatwe. Tkwiąc w tej sytuacji tracimy olbrzymią część naszego potencjału. Przekierowujemy naszą energię nie tam gdzie powinniśmy. Unikamy ryzyka, nawet gdy jest ono niewielkie. Jesteśmy ciągle w pozycji obronnej i ważymy nasze decyzje, aby tylko nie popełnić błędu, który będzie nam wytknięty. W naszych głowach świat tylko czyha na nasze potknięcie i pokazanie nam naszej nieudolności. Ciągła pozycja obronna nie daje nam możliwości na atak. Taka ofensywa związana z arsenałem jakim dysponujemy teraz albo arsenał jakiego nam brakuje, aby wyjść z okopów i zmierzyć się ze światem takim jakim on jest. Zobaczyć, że poza okopami jest wielu ludzi, którzy też z nich wyszli i zmierzają się ze swoimi słabościami oraz bronią się dzielnie również przed atakami tych, którzy z tych okopów nigdy nie wyjdą, ale z zaciekłością ich ostrzeliwują.\nAlternatywy Poza cytatem Teodora Roosvelta, w którym porównuje on tą walkę do wyjścia na ring, bardzo utwkił mi cytat Thomasa Watsona, dawnego szefa IBM. Zapytany czy zwolni pracownika, którego błąd kosztował firmę $600k, odpowiedział, że właśnie wydał te $600k na przeszkolenie tego pracownika i dziwi się jak mógłby tak wyszkolonego pracownika zwolnić. To wymaga radykalnej wręcz zmiany wizji świata. To wymaga akceptacji świata takim jakim jest. Wiem, to brzmi jak banał, ale pomaga wyjść z okopów. Jesteśmy tylko ludźmi i stworzeniami niedoskonałymi z założenia. Nawet natura popełnia błędy - w końcu sama ewolucja to pasmo prób i błędów. Wciąż zdarzają się potknięcia, choroby, katastrofy i rzeczy, na które nie mamy wpływu. Akceptujemy to jakim jest i szukamy rozwiązań, aby przeciwdziałać kataklizmom albo przynajmniej zminimalizować ich skutki. Dlaczego więc nie mielibyśmy postępować podobnie w przypadku, gdy mamy większy wpływ? Bo czyż nie jesteśmy sami w sobie taką małą ewolucją tylko o ograniczonym czasowo działaniu?\nKonstruktywna krytyka, a oderwanie od rzeczywistości Jak odróżnić krzyki narzekaczy od zgłaszanych faktycznych problemów związanych z naszą działalnością? Łatwo jest wszakże uznać, że każda krytyka jest bezpodstawna, a stoi za nią zawiść i inne emocje niekoniecznie związane z faktami. Tutaj pomocnym wydaje się zdrowe podejście związane z wiarygodnością źródła takich opinii. Zdecydowanie bardziej wiarygodni będą ci, którzy już są na ringu od wielu lat i przeżyli wiele bitew zdobywając więcej doświadczenia. Warto mieć grupę takich osób, które bez ogródek sprowadzą nas na ziemię kiedy trzeba i podpowiedzą rozwiązania, gdy faktycznie jest potrzebne działanie korygujące. Gorzej jest z krzykaczami i hejterami. Ich wiarygodność jest niska, ale zaangażowanie niezwykle wysokie. Ich działalność to ekstremalny przykład ludzi, którzy nigdy nie zamierzają wyjść i spróbować swoich sił, gdyż są za słabi. Wierzę jednak i widzę po różnych przykładach, że ich głos jest ledwo słyszalny gdy nie ma podstaw merytorycznych. Stąd warto skupiać się na dialogu z tymi, którym zależy na tym co tworzymy i słuchać ich głosu, szczególnie gdy nasze usługi adresowane są do szerszego grona odbiorców. Dobry produkt obroni się sam.\nNasze miejsce jest na ringu Zawsze będą tacy co wybiorą lożę szyderców będą podśmiewywać się z potknięć i upadków innych. Pozwólmy im tam zostać, a sami wyjść na ring, bo tam jest nasze miejsce. Tam czekają wzloty i upadki, ale to też tam marzenia są przekładane na rzeczywistość. Podziwiam tych co wychodzą codziennie na ring i używają swojej energii na tworzenie wartości. Trzymam kciuki, aby było nas coraz więcej!\n","tags":["perfekcjonizm"],"title":"Bezbłędni"},{"categories":["po-polsku"],"date":"December 8, 2020","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/pl/zosie-samosie/","section":"pl","summary":"Nie mam nic do Zoś. Moja babcia miała tak na imię i część dzieci moich znajomych nadaje je swoim córkom, bo to naprawdę piękne imię. Od mojego dzieciństwa tkwiło mi ono w głowie nie tylko w kontekście rodzinnym, ale również z powodu wiersza Juliana Tuwima “Zosia Samosia”. Idealnie opisuje on często spotykane podejście i nazwijmy go “samosizm”.\nÓw samosizm pomagał nam, Polakom w radzeniu sobie w trudnych czasach PRLu, gdzie trzeba było zdać się na siebie ze względu na brak materiałów i przede wszystkim pieniędzy. Stąd popularność ówczesnych programów typu “Zrób to sam” i propagowanie, również przez ówczesne władze, podejścia, że da się wszystko zrobić dobrymi chęciami. W końcu “Polak potrafi” jest mocno w nas zakorzenione i z dumą powtarzamy je przy różnego rodzaju wyzwaniach zawodowych.\nMożna byłoby szukać dalej przyczyn popularności naszego samosizmu, ale mnie bardziej interesują skutki, jakie to niesie dla nas w kontekście rodzimego rynku IT. Ta łatka samodzielności, którą nosimy jest również zauważna przez zachodnie firmy, które z chęcią przyjmują Polaków do trudnych zadań, bo kto jak nie my da radę. I ta zaradność to jest wspaniała cecha. Naprawdę! Zbudowaliśmy na niej wiele i pewnie zbudujemy jeszcze więcej, chcąc niejako nadrobić ten stracony czas PRLu, dogonić, a może i przegonić rozwinięte kraje zachodu.\nTo co mnie martwi to fakt, że takie podejście świetnie się sprawdziło, aby dojść do pewnego poziomu. Wydaje mi się, że już go osiągnęliśmy. Już nie musimy udowadniać, że potrafimy. Teraz potrzebujemy czegoś więcej. Potrzebujemy innowacyjności, a wytworzenie jej jest o wiele trudniejsze. I ten samosizm jest tutaj przeszkodą. To co kiedyś nam pomagało w odbudowaniu pewności siebie, teraz spowalnia nas w drodze do innowacji, która decyduje o tym czy dany kraj jest tylko konsumentem czy też producentem konkurencyjnych produktów.\nTeraz jesteśmy świetnym podwykonawcą produktów wymyślonych gdzieś na zachodzie. Potrzebujemy jednak zostać pomysłodawcą i opcjonalnie również wytwórcą. Do tego jednak potrzeba akceptacji faktu, że nie da się robić wszystkiego samodzielnie. Niezależnie od pobudek od tego faktycznego udowadniania, że potrafimy, aż po szukanie oszczędności, to brak takiej akceptacji jest wciskaniem hamulca na innowację w wyścigu, którego skutki możemy odczuć w najbliższych latach. Rozpraszanie energii na samodzielne budowanie niekrytycznych elementów produktu jest tutaj zbędne.\nPotrzebujemy zacząć korzystać z pomocy z zewnątrz - czy to jest gotowy produkt, za który trzeba płacić, czy też usługi doradcze i inne odciążające nas, a pozwalające skupić się na tworzeniu unikalnej wartości. Pomocne jest tutaj pytanie - czy faktycznie to co chcesz zrobić sam jest rdzenną częścią Twojego produktu? Skupienie się na faktycznie najważniejszej części biznesu może zwielokrotnić tempo jego rozwoju, a problemy pojawiające się w innych obszarach objętych opieką przez zewnętrzne produkty lub usługi mogą być zaadresowane często o wiele szybciej i lepiej.\nPolskie firmy muszą być bardziej konkurencyjne. Nie możemy pozostawać w roli podwykonawców, niezależnie jak dobrych i docenianych przez zachodnie firmy. Innowacja to ciężka praca, ale też pełne skupienie się na jej tworzeniu. Czas powiedzieć STOP samosizmowi.\n","tags":["perfekcjonizm"],"title":"Zosie Samosie"},{"categories":["articles"],"date":"September 26, 2020","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/how-to-modify-containers-without-rebuilding-their-image/","section":"articles","summary":"Containers are a beautiful piece of technology that ease the development of modern applications and also the maintenance of modern environments. One thing that draws many people to them is how they reduce the time required to set up a service, or a whole environment, with everything included. It is possible mainly because there are so many container images available and ready to use. You will probably need to build your own container images with your applications, but many containers in your environment will use prebuilt images prepared by someone else. It’s especially worth considering for software that is provided by the software vendor or a trusted group of developers like it has been done in the case of “official” images published on Docker Hub. In both cases, it makes your life easier by letting someone else take care of updates, packaging new versions, and making sure it works. But what if you want to change something in those images? Maybe it’s a minor change or something bigger that is specific for your particular usage of the service. The first instinct may tell you to rebuild that image. This, however, brings some overhead - these images will have to be published, rebuilt when new upstream versions are published, and you lose most of the benefits that come with those prebuilt versions. There is an alternative to that - actually, I found four of them which I will describe below. These solutions will allow you to keep all the benefits and adjust the behaviour of running containers in a seamless way.\nMethod 1 - init-containers Init-containers were created to provide additional functionality to the main container (or containers) defined in a Pod. They are executed before the main container and can use a different container image. In case of any failure, they will prevent the main container from starting. All logs can be easily retrieved and troubleshooting is fairly simple - they are fetched just like any other container defined in a Pod by providing its name. This methods is quiote popular among services such as databases to initialize and configure them based on configuration parameters.\nExample The following example uses a dedicated empty volume for storing data initialized by an init-container. In this specific case, it’s just a simple “echo” command, but in a real-world scenario, this can be a script that does something more complex.\napiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx name: nginx-init spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: initContainers: - name: prepare-webpage image: busybox:1.28 command: [\u0026#34;sh\u0026#34;, \u0026#34;-c\u0026#34;] args: [ \u0026#34;set -x; echo \u0026#39;Page prepared by an init container\u0026#39; \u0026gt; /web/index.html; echo \u0026#39;Init finished successfully\u0026#39; \u0026#34;, ] volumeMounts: - mountPath: /web name: web containers: - image: nginx:1.19 name: nginx volumeMounts: - mountPath: /usr/share/nginx/html/ name: web ports: - containerPort: 80 name: http volumes: - name: web emptyDir: {} Method 2 - post-start hook A Post-start hook can be used to execute some action just after the main container starts. It can be either a script executed in the same context as the container or an HTTP request that is executed against a defined endpoint. In most cases, it would probably be a shell script. Pod stays in the ContainerCreating state until this script ends. It can be tricky to debug since there are no logs available. There are more caveats and this should be used only for simple, non-invasive actions. The best feature of this method is that the script is executed when the service in the main container starts and can be used to interact with the service (e.g. by executing some API requests). With a proper readinessProbe configuration, this can give a nice way of initializing the application before any requests are allowed.\nExample In the following example a post-start hook executes the echo command, but again - this can be anything that uses the same set of files available on the container filesystem in order to perform some sort of initialization.\napiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx name: nginx-hook spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx:1.19 name: nginx ports: - containerPort: 80 name: http lifecycle: postStart: exec: command: [ \u0026#34;sh\u0026#34;, \u0026#34;-c\u0026#34;, \u0026#34;sleep 5;set -x; echo \u0026#39;Page prepared by a PostStart hook\u0026#39; \u0026gt; /usr/share/nginx/html/index.html\u0026#34;, ] Method 3 - sidecar container This method leverages the concept of the Pod where multiple containers run at the same time sharing IPC and network kernel namespaces. It’s been widely used in the Kubernetes ecosystem by projects such as Istio, Consul Connect, and many others. The assumption here is that all containers run simultaneously which makes it a little bit tricky to use a sidecar container to modify the behaviour of the main container. But it’s doable and it can be used to interact with the running application or a service. I’ve been using this feature with the Jenkins helm chart where there’s a sidecar container responsible for reading ConfigMap objects with Configuration-as-Code config entries.\nExample Nothing new here, just the “echo” command with a little caveat - since sidecar containers must obey restartPolicy setting, they must run after they finish their actions and thus it uses a simple while infinite loop. In more advanced cases this would be rather some small daemon (or a loop that checks some state) that runs like a service.\napiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx name: nginx-sidecar spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx:1.19 name: nginx volumeMounts: - mountPath: /usr/share/nginx/html/ name: web ports: - containerPort: 80 name: http - name: prepare-webpage image: busybox:1.28 command: [\u0026#34;sh\u0026#34;, \u0026#34;-c\u0026#34;] args: [ \u0026#34;set -x; echo \u0026#39;Page prepared by a sidecar container\u0026#39; \u0026gt; /web/index.html; while :;do sleep 9999;done \u0026#34;, ] volumeMounts: - mountPath: /web name: web volumes: - name: web emptyDir: {} Method 4 - entrypoint The last method uses the same container image and is similar to the Post-start hook except it runs before the main app or service. As you probably know in every container image there is an ENTRYPOINT command defined (explicitly or implicitly) and we can leverage it to execute some arbitrary scripts. It is often used by many official images and in this method we will just prepend our own script to modify the behavior of the main container. In more advanced scenarios you could actually provide a modified version of the original entrypoint file.\nExample This method is a little bit more complex and involves creating a ConfigMap with a script content that is executed before the main entrypoint. Our script for modifying nginx entrypoint is embedded in the following ConfigMap\napiVersion: v1 kind: ConfigMap metadata: name: scripts data: prestart-script.sh: |- #!/usr/bin/env bash echo \u0026#39;Page prepared by a script executed before entrypoint container\u0026#39; \u0026gt; /usr/share/nginx/html/index.html exec /docker-entrypoint.sh nginx -g \u0026#34;daemon off;\u0026#34; # it\u0026#39;s \u0026#34;ENTRYPOINT CMD\u0026#34; extracted from the main container image definition One thing that is very important is the last line with exec. It executes the original entrypoint script and must match it exactly as it is defined in the Dockerfile. In this case it requires additional arguments that are defined in the CMD.\nNow let’s define the Deployment object:\napiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx name: nginx-script spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx:1.19 name: nginx command: [\u0026#34;bash\u0026#34;, \u0026#34;-c\u0026#34;, \u0026#34;/scripts/prestart-script.sh\u0026#34;] ports: - containerPort: 80 name: http volumeMounts: - mountPath: /scripts name: scripts volumes: - name: scripts configMap: name: scripts defaultMode: 0755 # \u0026lt;- this is important That is pretty straightforward - we override the entrypoint with command and we also must make sure our script is mounted with proper permissions (thus defaultMode needs to be defined).\nComparison table Here’s the table that summarizes the differences between the aforementioned methods:\nConclusion Containers are about reusability and often it’s much easier to make small adjustments without rebuilding the whole container image and take over the responsibility of publishing and maintaining it. It’s just an implementation of the KISS principle.\n","tags":["containers","docker","kubernetes"],"title":"How to modify containers without rebuilding their image"},{"categories":["newsletter"],"date":"July 13, 2020","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/newsletter-archive/1-test/","section":"newsletter-archive","summary":"Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.\nLorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.\n\u0026ldquo;The public is more familiar with bad design than good design. It is, in effect, conditioned to prefer bad design, because that is what it lives with. The new becomes threatening, the old reassuring.\u0026rdquo; \u0026ndash; Benjamin Franklin\nLorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.\nROFL means Rolling on floor laughing. STFU means Shut the freak up. LMK means Let me know. ILY means I love you. YOLO means You only live once. SMH means Shaking my head. The company was previously known as Hingston + Co. but has been given a complete rebrand — including a new logo, tap badges, website and branded material — by London-based design studio \u0026amp; Smith. The new identity is based on the Kandinsky abstract painting, Black Lines, and true to its name, is mostly black and white with a few flashes of colour. According to \u0026amp; Smith, the identity brings together “art and science” and has been brought to life through collaborations with nine illustrators.\nsanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat.\nBlack Lines wants it to be as easy to serve a Negroni as it is a pint of lager. The drinks company is seeking to revolutionise the bar experience by serving cocktails by draught with a changing menu of drinks (as well as same favourite stand-bys). A pink grapefruit spritz was served through the summer while a new pear and white tea fizz joins the line-up for winter.\n","tags":["Mobile","devops"],"title":"B. Franklins thoughts about designers"},{"categories":["articles"],"date":"March 14, 2020","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/4-ways-to-manage-kubernetes-resources/","section":"articles","summary":"Kubectl is the new ssh When I started my adventure with linux systems the first tool I had to get to know was ssh. Oh man, what a wonderful and powerful piece of software it is! You can not only log in to your servers, copy files, but also create vpns, omit firewalls with SOCKS proxy and port-forwarding rules, and many more. With Kubernetes, however, this tool is used mostly for node maintenance provided that you still need to manage them and you haven’t switched to CoreOS or another variant of the immutable node type. For any other cases, you use kubectl which is the new ssh. If you don’t use API calls directly then you probably use it in some form and you feed it with plenty of yaml files. Let’s face it - this is how managing Kubernetes environment looks like nowadays. You create those beautiful, lengthy text files with the definitions of the resources you wish to be created by Kubernetes and then magic happens and you’re the hero of the day. Unless you want to create not one but tens or hundreds of them with different configurations. And that’s when things get complicated.\nSimplicity vs. flexibility For basic scenarios, simple yaml files can be sufficient. However, with the growth of your environment, the number of resources and configurations grows. You may start noticing how much more time it takes to create a new instance of your app, reconfigure the ones that are running already or share it with the community or with your customers wishing to customize it to their needs. Currently, I find the following ways to be the most commonly used:\nPlain yaml files Kustomize Helm Charts Operators They all can be used to manage your resources and they also are different in many ways. One of the distinguishing factors is complexity which also implies much effort to learn, use and maintain a particular method. On the other hand, it might pay off in the long run when you really want to create complex configurations. You can observe this relationship in the following diagram:\n[caption id=\u0026ldquo;attachment_1674\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;920\u0026rdquo;] Flexibility vs. Complexity[/caption]\nSo there’s a trade-off between how much flexibility you want to have versus how simple it can be. For some simplicity can win and for some, it’s just not enough. Let’s have a closer look at these four ways and see in which cases they can fit best.\n1. Keep it simple with plain yamls I’ve always told people attending my courses that by learning Kubernetes they become yaml programmers. It might sound silly, but in reality, the basic usage of Kubernetes comes down to writing definitions of some objects in plain yaml. Of course, you have to know two things - the first is what you want to create, and the second is the knowledge on Kubernetes API which is the foundations of these yaml files. After you’ve learned how to write yaml files you can just use kubectl to send it to Kubernetes and your job is done. No parameters, no templates, not figuring out how to change it in a fancy way. If you want to create an additional instance of your application or the whole environment you just copy and paste. Of course, there will be some duplication here but it’s the price you pay for simplicity. And besides, for a couple of instances it’s not a big deal and most of the organizations probably can live with this imperfect solution, at least at the beginning of their journey when they are not as big as they wish to be.\nWhen to use:\nFor projects with less than 4 configurations/instances of their apps or environments For small startups For bigger companies starting their first Kubernetes projects (e.g. as a part of PoC) For individuals learning Kubernetes API When to avoid:\norganizations and projects releasing their products or services for Kubernetes environments in projects where each instance varies significantly and requires a lot of adjustments 2. Customize a bit with Kustomize Kustomize is a project that is one of Kubernetes official SIG groups. It has the concept of inheritance based Kubernetes resources defined in.. yaml files. That’s right - you cannot escape from them! This time, however, with Kustomize you can apply any changes you want to your already existing set of resources. To put it simply Kustomize can be treated as a Kubernetes-specific patch tool. It lets you override all the parts of yaml files with additional features, including the following:\nChanging repositories, names, and tags for container images Generating ConfigMap objects directly from files and generate hashes ensuring that Deployment will trigger a new rollout when they change Using kustomize cli to modify configurations on the fly (useful in CI/CD pipelines) From version 1.14 it is built-in to kubectl binary which makes it easy to start with. Unfortunately, new features are added much faster in standalone kustomize project and its release cycle doesn’t sync up with the official releases of kubectl binaries. Thus, I highly recommend using its standalone version rather than kubectl’s built-in functionality. According to its creators, it encourages you to use Kubernetes API directly without creating another artificial abstraction layer.\nWhen to use:\nFor projects with less than 10 configurations/instances that don’t require too many parameters For startups starting to grow, but still using Kubernetes internally (i.e. without the need to publish manifests as a part of their products) For anyone who knows Kubernetes API and feels comfortable with using it directly When to avoid:\nIf your environments or instances vary up to between 30-50%, because you’ll just rewrite most of your manifests by adding patches In the same cases as with plain yamls 3. Powerful Helm Charts for advanced If you haven’t seen Helm Hub then I recommend you to do it and look for your favorite software, especially if it’s a popular open-source project, and I’m pretty sure it’s there. With the release of Helm 3 most of its flaws have been fixed. Actually the biggest one was the Tiller component that is no longer required which makes it really great tool for your deployments. For OpenShift users that could also be a great relief since its templating system is just too simple (I’m trying to avoid word terrible but it is). Most people who have started using Helm for deploying these ready services often start writing their own Charts for applications and almost everything they deploy on Kubernetes. It might be a good idea for really complex configurations but in most cases, it’s just overkill. In cases when you don’t publish your Charts to some registry (and soon even to container registries) and just use them for their templating feature (with Helm 3 it is finally possible without downloading Chart’s source code), you might be better of with Kustomize. For advanced scenarios, however, Helm is the way to go. It can be this single tool that you use to release your applications for other teams to deploy to their environments. And so can your customers who can use a single command - literally just helm upgrade YOURCHART - to deploy a newer version of your app. All you need to do in order to achieve this simplicity is “ just”:\nwrite Chart templates in a way that would handle all these cases and configuration variants create and maintain the whole release process with CI/CD pipeline, testing, and publishing Many examples on Helm Hub shows how complex software can be packed in a Chart to make installation a trivial process and customization much more accessible, especially for end-users who don’t want to get into much details. I myself use many Helm Charts to install software and consider it as one of the most important projects in Kubernetes ecosystem.\nWhen to use:\nFor big projects with more than 10 configurations/instances that have many variants and parameters For projects that are published on the Internet to make them easy to install When to avoid:\nIf your applications are not that complex and you don’t need to publish them anywhere If you don’t plan to maintain CI/CD for the release process cause maintaining Charts without pipelines is just time-consuming If you don’t know Kubernetes API in-depth yet 4. Automated bots (operators) at your service Now, the final one, most sophisticated, and for some superfluous. In fact, it’s a design pattern proposed by CoreOS (now Red Hat) that just leverages Kubernetes features like Custom Resource Definition and custom logic embedded in software running directly on Kubernetes and leveraging its internal API called controllers. It is widely used in the OpenShift ecosystem and it’s been promoted by Red Hat since the release of OpenShift 4, as the best way to create services on OpenShift. They even provide an operator for customizing OpenShift’s web interface. That’s what I call an abstraction layer! Everything is controlled there with yaml handled by dozens of custom operators, because the whole logic is embedded there. To put it simply what is operator I would say that operator is an equivalent of cloud service like Amazon RDS, GCP Cloud Pub/Sub or Azure Cosmos DB. You build an operator to provide a consistent, simple way to install and maintain (including upgrades) your application in ”-as-a-Service” way on any Kubernetes platform using its native API. It does not only provide the highest level of automation, but also allows for including complex logic such as built-in monitoring, seamless upgrades, self-healing and autoscaling. Once again - all you need to do is provide a definition in yaml format and the rest will be taken care of by the operator. “It looks awesome!” one can say. Many think it should and will be a preferred way of delivering applications. I cannot agree with that statement. I think if you’re a software vendor providing your application to hundreds of customers (even internally) then this is the way to go. Otherwise, it can be too complex and time consuming to write operators. Especially if you want to follow best practices, use Golang and provide an easy upgrade path (and it can get tricky).\nI found the following projects to be very helpful in developing and maintaining Operators:\nkubebuilder - one of the first operator frameworks for Go developers, the most poweful and the most complex one kopf - framework for developing operators in python KUDO - write operators in a declarative way operator-sdk - framework from CoreOSRed Hat for writing operators in Go and Ansible operator-lifecycle - a must have for anyone interested in getting serious with operators and their lifrecycle (installation, maintenance, upgrades) When to use:\nIf you need to create your own service (e.g. YourProduct-as-a-Service) available on Kubernetes If you plan to add additional features to your service (e.g. monitoring, autoscaling, autohealing, analytics) If you’re a software vendor providing your software for Kubernetes platforms If you want to develop software installed on OpenShift and be a part of its ecosystem (e.g. publish your software on their ”app marketplace” - operatorhub.io) When to avoid:\nFor simple applications For other applications when Helm Chart with some semi-complex templates will do When no extra automation is needed or it can be acomplished with simple configuration of the existing components Conclusion Each of these methods and tools I have described are for organizations at different point of their journey with Kubernetes. For standard use-cases simple yamls may be sufficient and with more applications Kustomize can be great enhancement of this approach. When things get serious and applications get more complex, Helm Chart presents a perfect balance between complexity and flexibility. I can recommend Operators for vendors delivering their applications in Kubernetes in a similar way to cloud services, and definitely for those who plan to provide it for enterprise customers using OpenShift.\n","tags":["containers","kubernetes","kustomize","openshift","operator"],"title":"4 ways  to manage Kubernetes resources"},{"categories":["articles"],"date":"February 21, 2020","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/why-vault-and-kubernetes-is-the-perfect-couple/","section":"articles","summary":"The (not so) secret flaws of Kubernetes Secrets When you’re starting learning and using Kubernetes for the first time you discover that there is this special object called Secret that is designed for storing various kinds of confidential data. However, when you find out it is very similar to ConfigMap object and is not encrypted (it can be optionally encrypted at rest) you may start wondering - is it really secure? Especially when you use the same API to interact with it and the same credentials. This, combined with a rather simple RBAC model, can create many potential risks. Most people would stick with one of three default roles for regular users - view, edit, and admin - with view as the only one that forbids viewing Secret objects. You need to be very careful when assigning roles to users or deciding to create your custom RBAC roles. But again, this is also not that easy since RBAC rules can only whitelist API requests - it is not possible to create exceptions (i.e. create blacklists) without using the external mechanism such as Open Policy Agent.\nManaging Secrets is Hard On top of that managing Secret object definitions (e.g. yaml files) is not an easy task. Where should you store it before sending it to your Kubernetes cluster - in a git repo? Outside of it? Who should have access to view and modify it? What about encryption - should it be encrypted with a single key shared by the trusted team members or with gpg (e.g. git-secret, git-crypt)? One thing is for sure - it is hard to maintain Secret object definitions in the same way as other Kubernetes objects. You can try to come up with your own way of protecting them, auditing changes and other important things you’re not even aware of, but why reinvent the wheel when there’s something better? Much, MUCH better.\nHashiCorp Vault to the Rescue Now some may say I am a HashiCorp fanboy which… might be partially true :) I not only love their products but more their approach towards managing infrastructure and the fact that most features they provide are available in open source versions. It is not a surprise that the best product they have on offer (in terms of commercial success) is Vault. It is a project designed to help you store and securely access your confidential data. It is designed for this purpose only and has many excellent features among which you will also find many that are specific for Kubernetes environments.\nBest features of Vault I’m not going to list out all of the features - they are available in the official documentation. Let me focus on the most important ones and the ones also related to Kubernetes.\nOne security-dedicated service enterprise features The fact that it’s a central place where you store all your confidential data may be alarming at first, but Vault offers many interesting functionalities that should remove any doubts in its security capabilities. One of them is the concept of unsealing Vault after start or restart. It is based on a Shamir’s Secret Sharing concept which requires the usage of multiple keys that should be owned and protected by different people. This definitely decreases the chance of interfering or tampering with stored data, as the whole process imposes transparency of such actions. Of course there’s audit, high availability and access defined with well-documented policies.\nAbility to store various type of data The first thing that people want to store in places like Vault are passwords. This is probably because we use them most often. However, if you want to deploy Vault only for this purpose you should reconsider it, cause it’s much more powerful and it’s like driving a Ferrari using 1st gear only. Vault has many secret engines designed for different kind of data. The basic one - KV (Key-Value) - can be used for store any arbitrary data with advanced versioning. It can also act as your PKI or Time-based One Time Passwords(similar to Google Authenticator). But that’s not all. In my opinion, the real power of Vault lies in dynamic secrets.\nForget your passwords with dynamic secrets It’s my personal opinion and I think that many people will agree with me that dynamic secrets are the best feature of Vault. If there was a single reason for me to invest my time and resources to implement Vault in my organization that would be it. Dynamic secrets change the way you handle authentication. Instead of configuring static passwords you let Vault create logins and passwords on the fly, on-demand, and also with limited usage time. I love the fact that Vault also rotates not only users passwords but also administrators as well, cause let’s be honest - how often do you change your password to your database and when the last time you did it? Vault can manage access to your services instead of only storing static credentials and this is a game-changer. It can manage access to databases, cloud ( AWS, Azure, Google), and many others.\nNo vendor lock-in There are various cloud services available that provide similar, however limited in features, functionality. Google recently announced their Secret Manager, AWS has Parameter Store, and Azure offers Key Vault. If you’re looking for a way to avoid vendor lock-in and keep your infrastructure portable, multi-cloud enabled and feature-rich then Vault will satisfy your needs. Let’s not forget about one more important thing - not every organization uses cloud and since Vault can be installed anywhere it also suits these environments perfectly.\nMultiple authentication engines with excellent Kubernetes support In order to get access to credentials stored in Vault you need to authenticate yourself and you have plenty of authentication methods to choose from. You can use simple username and password, TLS certificates but also use your existing accounts from GitHub, LDAP, OIDC, most cloud providers and many others. These authentication engines can be used by people in your organization and also by your applications. However, when designing access for your systems, you may find other engines to be more suitable. AppRole is dedicated to those scenarios and it is a more generic method for any applications, regardless of the platform they run on. When you deploy your applications on Kubernetes you will be better off with native Kubernetes support. It can be used directly by your application, your custom sidecar or Vault Agent.\nNative Kubernetes installation Since Vault is a dedicated solution for security, proper deployment can be somewhat cumbersome. Fortunately, there is a dedicated installation method for Kubernetes that uses a Helm Chart provided and maintained by Vault’s authors (i.e. HashiCorp). Although I really like and appreciate that feature I would use it only for non-production environments to speed up the learning process. For production deployments, I would still use traditional virtual machines and automate it with Terraform modules - they are also provided by HashiCorp in Terraform registry (e.g. for GCP).\nWhy it is now easier than ever Until recently using Vault with Kubernetes required some additional, often complicated steps to provide secrets stored in Vault to an application running on Kubernetes. Even with Vault Agent you’re just simplifying only the token fetching part and leaving you with the rest of the logic i.e. retrieving credentials and making sure they are up to date. With additional component - Agent Sidecar Injector - the whole workflow is very simple now. After installing and configuring it (you do it once) any application can be provided with secrets from Vault in a totally transparent way. All you need to do is to add a few annotations to your Pod definitions such as these:\nspec: template: metadata: annotations: vault.hashicorp.com/agent-inject: \u0026#34;true\u0026#34; vault.hashicorp.com/agent-inject-secret-helloworld: \u0026#34;secrets/helloworld\u0026#34; vault.hashicorp.com/role: \u0026#34;myapp\u0026#34; No more writing custom scripts, placing them in a separate sidecar or init containers - everything is managed by Vault components designed to offload you from these tasks. It has really never been that easy! In fact, this combined with dynamic secrets described earlier, creates a fully passwordless solution. Access is managed by Vault and your (or your security team’s) job is to define which application should have access to particular services. That’s what I call a seamless and secure integration!\nConclusion I’ve always been a fan of HashiCorp products and at the same time I’ve considered Kubernetes Secrets as an imperfect solution for providing proper security for storing credentials. With the excellent support for Kubernetes in Vault now we finally have a missing link in a form of a dedicated service with proper auditing, modularity and ease of use. If you think seriously about securing your Kubernetes workloads, especially in an enterprise environment, then HashiCorp Vault is the best solution there is. Look no further and start implementing - you’ll thank me later.\n","tags":["kubernetes","openshift","security","vault"],"title":"Why Vault and Kubernetes is the perfect couple"},{"categories":["articles"],"date":"October 23, 2019","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/how-to-build-cicd-pipelines-on-kubernetes/","section":"articles","summary":"Kubernetes as a standard development platform We started with single, often powerful, machines that hosted many applications. Soon after came virtualization, which didn’t actually change a lot from a development perspective but it did for the field of operations. So developers became mad, and that’s when the public cloud emerged to satisfy their needs instead of operations guys’. Now, this pendulum has moved once again and we have something that is beneficial for both sides - Kubernetes platform. I keep saying and will repeat it here again - I think it’s one of the best projects that have emerged in the last decade. It has completely changed the perspective of how we deliver applications and also how we manage platforms for them. This time I want to focus on the delivery process and how it can be built and what the real benefits of using Kubernetes for that purpose are.\nHow CI/CD is different in Kubernetes There are a couple of differences that actually are results of its design and usage of containers in general.\nEverything is distributed Kubernetes was built to satisfy the growing requirements of applications that run on a larger scale than ever before. Therefore applications can run on any node in a cluster and although you can control it, you shouldn’t unless you really have to. Nodes can also be distributed among different availability zones and you should actually treat them in the same way as containers - they are ephemeral and disposable.\nApplications and services are delivered in immutable container images No more quick changes or hotfixes applied to live (sometimes even production) environments. That’s something that many people cannot comprehend and is sometimes frustrating. In order to change something now, you need to build a new version of an application (the harder part) or change something within your environment (the easier part - e.g. changing firewall rules with NetworkPolicy, changing a configuration with ConfigMap etc.).\nChanges in application environments are controlled with yaml files From the platform management perspective, this is a huge improvement. Since Kubernetes is a declarative system, every change can be described as a set of yaml files. It can be intimidating at first but brings stability, predictability, and security to the whole process.\nEverything as code I guess this just sums up the previous points. When you maintain an environment for your applications you actually need to manage changes through files that you version, test and improve with great care. It can also involve every part of your environment starting from infrastructure (e.g. cloud or on-premise hardware) through Kubernetes cluster(s) and ending with environments containing your applications.\nHow can you improve your delivery process with Kubernetes features Maybe you already have existing environments with nice CI/CD pipelines and you may wonder what are the real benefits of using Kubernetes for your applications. I personally see a lot of them and let’s go through the most important ones.\nIncreased transparency and trackability of changes Has someone ever made an unpleasant surprise on your test or staging environment? I’m pretty sure it was made with good intentions, but often these unexpected changes lead to unnecessary hours of troubleshooting and frustration. With everything kept in yaml files and maintained as code in versioned git repositories with all good practices around it (i.e. code review, tests) these kinds of surprises should not happen. With the well-designed delivery process, all changes are trackable and no manual action performed outside of the standard process could affect working applications.\nTest environments available rapidly, on-demand and in large quantities Whenever there’s a need for a new environment for testing it often takes not only many resources but also a very long time. Thanks to Kubernetes and its ability to create environments from scratch using just yaml files it’s just really trivial. You can create them as many as you want since they are composed mostly of logical objects to separate and distinguish them - you are only limited by the resources available on your cluster. But cluster is also quite easily expandable it’s just a matter of something that is not - money you are able to put in your project.\nEasier management of applications developed by multiple teams Most people are attracted to Kubernetes as a platform for deployments for their microservices. Although it’s also a perfect place for other services (including queue systems, databases, etc.) it brings a lot of benefits for teams who develop their applications as microservices. Often a single team is responsible for many applications and also many teams work on a system that comprises dozens of microservices. That’s where it may be handy to have a standardized way of setting up and maintain the whole CI/CD process from one place. I recommend my approach with factories which I described in my article. Especially when you have dozens of microservices and teams responsible for them it is crucial to have a common approach that is scalable and maintainable (of course using code).\nIncreased security of your applications and environments With Cloud Native approch you don’t build applications - you build complete environments. To be precise you create environments from versioned code and run your service from immutable container image with all dependencies included. And when it comes to these immutable images you can now scan them for vulnerabilities after they are built but also constantly as a background process which marks them as insecure to deploy. Environments configuration can be secured with a proper process created around maintenance and governance of object definition kept as code. No unapproved or unknown change should be allowed that would compromise platform security and all services running on it.\nEasier testing with databases available on-demand Unless your applications are totally stateless and don’t need any external service then probably one of its dependencies is some kind of database. I know that’s always been a pain point in terms of testing new versions that require a new database instance and it always takes a long time to get one. Now thanks to containers we can create a new instance in a minute or so. And I’m not talking only about MySQL or PostgreSQL - did you know that you can run MS SQL Server and Oracle databases too? (although you need to talk with them about licensing since you never knows is appropriate or not). I would definitely recommend using operator frameworks such as KubeDB or other operators available at OperatorHUB.\nDesigning and building CI/CD pipeline Let’s dig into more technical details now. I’m going to describe the whole process of designing and building CI/CD pipeline for an application running on Kubernetes.\nStep 1 - Split CI/CD into CI and CD [caption id=\u0026ldquo;attachment_1684\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;902\u0026rdquo;] CI and CD[/caption] It sounds trivial but many people believe it should go together. No, it doesn’t. You should split it into two separate processes, even if you’ll put it into a single pipeline. When you join them you often tend to use the same or similar tools for both parts and you just make it too complex at times. Define clear goals of both parts:\nCI - build and test application artifacts CD - deploy artifacts created as a part of CI to Kubernetes environment Tools You definitely need some orchestrator that would be responsible for the delivery process. Here are some of the best solutions* available now:\nJenkins - of course, it’s my favorite one, to find out why please see my article on Jenkins where I show why it’s still one of the best choices for CI/CD orchestrator) GitLab CI - pretty nice and very popular, not as powerful as Jenkins but easy to use with container registry built-in and it’s also a Git server Jenkins-X - a powerful engine for automated builds; you actually don’t create any pipelines by yourself but rather use the one generated by Jenkins-X Tekton - a cloud-native pipeline orchestrator that is under heavy development (it’s still in alpha); in a couple of months it should be a full-fledged CI/CD solution * projects available on all platforms - cloud and on-premise\nStep 2 - Split CI into three parts [caption id=\u0026ldquo;attachment_1685\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;902\u0026rdquo;] Three stages of CI[/caption] Let’s split the whole CI into three parts. We’re going to do it in order to simplify and to have more choices for tools that we’re going to use. Continuous Integration for applications running on Kubernetes distinguishes itself with one important detail - we not only provide artifacts with applications but also with its environment definition. We must also take that into consideration.\n2.1 Build application artifact GOAL: Create, test and publish (optionally) artifact with application\nIn this step, we need to build an artifact. For applications requiring compilation step that would produce a binary package that should be built in a pristine, fresh environment using an ephemeral container.\nTOOLS\nIt depends on your application. The most important thing here is to leverage Kubernetes platform features to speed up and standardize the build process. I recommend using ephemeral containers for the building process to keep it consistent across all builds. These containers should have already necessary tools built-in (e.g. maven with JDK, nodejs, python etc.). I can also recommend using Source-To-Image (source mode) for small projects, especially if you’re running them on OpenShift. It brings the highest automation and standardization using images based on RHEL which is a nice feature appreciated by security teams.\nEXAMPLE\nHere’s an excerpt from a Jenkinsfile for my sample application written in go. It uses a Jenkins slave launched as a container in a pod on a Kubernetes cluster.\nstage(\u0026#39;Build app\u0026#39;) { agent { kubernetes { containerTemplate { name \u0026#39;kubectl\u0026#39; image \u0026#39;golang:1.12-buster\u0026#39; ttyEnabled true command \u0026#39;cat\u0026#39; } } } steps { sh \u0026#39;go get -d\u0026#39; sh \u0026#39;make test\u0026#39; sh \u0026#39;make build’ stash name: \u0026#34;app\u0026#34;, includes: \u0026#34;cow\u0026#34; } } 2.2 Build container image GOAL: Build a container image, assign tag and publish it to a container registry\nIt’s pretty straightforward - we need to publish a container image with our application built in the previous step.\nTOOLS\nI love the simplicity and I also like Source-To-Image (binary mode) to create container images in a standardized way without defining any Dockerfiles. If you need to define them please consider using Kaniko - it can use existing Dockerfile but it’s simpler and doesn’t require any daemon running on a host as Docker does.\nEXAMPLE\nIn my sample app, I use kaniko to build a container image without any Docker daemon running (Jenkins runs on Kubernetes and should not have a direct connection to Docker since it’s insecure). I use a custom script to test it also outside of Jenkins pipeline and because Jenkins is meant to be used as an orchestrator, not a development environment (according to its founders).\nstage(\u0026#39;Build image\u0026#39;) { agent { kubernetes { yamlFile \u0026#34;ci/kaniko.yaml\u0026#34; } } steps { container(name: \u0026#39;kaniko\u0026#39;, shell: \u0026#39;/busybox/sh\u0026#39;) { unstash \u0026#39;app\u0026#39; sh \u0026#39;\u0026#39;\u0026#39; /busybox/sh ci/getversion.sh \u0026gt; .ci_version ver=`cat .ci_version` ci/build-kaniko.sh cloudowski/test1:$ver Dockerfile.embed \u0026#39;\u0026#39;\u0026#39; } } } 2.3 Prepare Kubernetes manifests GOAL: Prepare Kubernetes manifests describing the application and its environment\nThis step in Kubernetes specific. Building application is not only about providing binary container image but also about delivering proper manifests describing how it should be deployed (how many instances, affinity rules, what storage should be used etc.) and how its environment should be configured (what credentials to use for connecting to database, cpu reservation and limits, additional roles to be used by it etc.).\nTOOLS\nThe simplest solution here is to use plain yaml files. Of course for bigger environments, it’s just too hard to manage and I would still recommend going with yaml files and Kustomize. Simplicity over complexity. When it comes to the latter the most commonly used software is, of course, Helm with its Charts. I don’t like it (and many others as well) mainly because of its Tiller component that makes it vulnerable and insecure. With version 3 and all these problems resolved it would be a better solution with a powerful templating system (if you really, really need it).\nStep 3 - Deploy to preview environments [caption id=\u0026ldquo;attachment_1686\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;901\u0026rdquo;] Deployment to preview and permanent environments[/caption]\nGOAL: Enable testing configuration and container image before releasing\nIt’s a highly coveted feature by developers - to have a dedicated and separated environment that can be used for testing. This preview environment can be created automatically (see example below) by leveraging Kubernetes manifests describing it.\nTOOLS\nThere are no dedicated tools but I find Kustomize with its overlay feature to be perfect for it although you need a custom solution that can be integrated with your CI/CD orchestrator (i.e. triggering a deployment on certain conditions). Of course, other solutions (e.g. Helm Chart) are also viable - you just need to use namespaces and define all necessary objects there.\nEXAMPLE\nIn my example, I’m using a dedicated container image with Kustomize binary in it and a custom script that handles all the logic. It creates a dedicated namespace and other objects kept in the same repository using Kustomize overlay with a proper name derived from a branch name.\nstage(\u0026#39;Deploy preview\u0026#39;) { agent { kubernetes { serviceAccount \u0026#39;deployer\u0026#39; containerTemplate { name \u0026#39;kubectl\u0026#39; image \u0026#39;cloudowski/drone-kustomize\u0026#39; ttyEnabled true command \u0026#39;cat\u0026#39; } } } steps { sh \u0026#39;ci/deploy-kustomize.sh -p\u0026#39; } when { // deploy on PR automatically OR on non-master when commit starts with \u0026#34;shipit\u0026#34; anyOf { allOf { changelog \u0026#39;^shipit ?.+ Step 4 - Prepare promotion step [caption id=\u0026ldquo;attachment_1687\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;903\u0026rdquo;] Promote artifacts[/caption] GOAL: Release artifacts and start the deployment process\nAfter the container image is ready, all the tests pass successfully, code review acknowledges it’s proper quality, you can now promote your changes and initiate the deployment to the production environment through all required intermediate environments (e.g. test, stage).\nTOOLS\nPromotion could be done entirely in Git by merging development or features branches with a release branch (e.g. master).\nStep 5 - Deploy to permanent environments GOAL: Deliver applications to production through a hierarchy of test environments\nIt’s an important step and quite simple at the same time. We have all the necessary artifacts available and we just need to deploy them to all of the persistent environments, including production. In the example below there are only stage and prod as persistent environments and there are no tests here. However, this is a perfect place to perform some more complex tests like stress, performance and security testing. Please note that the production environment often runs on a separate cluster but that can be easily handled by just changing a context for kubectl before applying changes on it.\nTOOLS\nNo new tools here, just an API request or a click on the web console is required to push your new version through the rest of the pipeline.\nstage(\u0026#39;Deploy stage\u0026#39;) { agent { kubernetes { serviceAccount \u0026#39;deployer\u0026#39; containerTemplate { name \u0026#39;kubectl\u0026#39; image \u0026#39;cloudowski/drone-kustomize\u0026#39; ttyEnabled true command \u0026#39;cat\u0026#39; } } } steps { sh \u0026#39;ci/deploy-kustomize.sh -t kcow-stage\u0026#39; // rocketSend channel: \u0026#39;general\u0026#39;, message: \u0026#34;Visit me @ $BUILD_URL\u0026#34; } when { allOf { // changelog \u0026#39;^deploy ?.+ Conclusion I always tell to my clients - it has never been easier to improve your environments and speed up delivery of your applications. With proper CI/CD pipeline, all of these new tools, the declarative nature of Kubernetes, we are now able to keep it under control and continuously improve it. You should leverage containers to make it repeatable, portable and also more flexible - developers will have more ways to test and experiment, security teams will have full insight into all changes being made to the system, and finally, your end-users will appreciate fewer bugs and more features introduced in your applications\n","tags":["cicd","containers","kubernetes","openshift"],"title":"How to build CI/CD pipelines on Kubernetes"},{"categories":["articles"],"date":"August 29, 2019","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/10-most-important-differences-between-openshift-and-kubernetes/","section":"articles","summary":"UPDATED on 10.6.2019 (after the release of OpenShift 4.1): Added information on OpenShift 4.\nUPDATED on 30.8.2019: Added information on CodeReady Containers for running single OpenShift node.\nOpenShift has been often called as “Enterprise Kubernetes” by its vendor - Red Hat. In this article, I’m describing real differences between OpenShift and Kubernetes. It’s often confusing, as Red Hat tends to describe it as PaaS, sometimes hiding the fact that Kubernetes is an integral part of OpenShift with more features built around it. Let’s dive in and check what are the real differences between those two.\n1. OpenShift product vs. Kubernetes project Kubernetes is an open source project (or even a framework), while OpenShift is a product that comes in many variants. There’s an open source version of OpenShift which is called OKD. Previously it was called OpenShift Origin, but some “clever” folks at Red Hat came up with this new name which supposes to mean “The Origin Community Distribution of Kubernetes that powers Red Hat OpenShift” (?). But let’s forget about names for a while and focus on what are implications of that.\nThere are a couple of them:\nOpenShift Container Platform is a product that you can install on your infrastructure that has a paid support included that comes with a subscription You need to renew your OpenShift subscription for your cluster and you pay more when your cluster grows Kubernetes has many distributions, but it’s a project and if something bad happens you can count mostly on community or external experts (in some cases they might be sometimes better than Red Hat support :-) ) Kubernetes has many releases per year (4 actually), OpenShift has also many releases, but it falls behind Kubernetes release schedule - version 3 at the time of writing was far behind (it includes Kubernetes 1.11 while the newest release was 1.14) while version 4 was “only” one release behind and should follow upstream Kubernetes in the future releases As a product OpenShift subscription includes CloudForms (only in version 3) that enhance it with its features (e.g. configurable chargeback, monitoring, central provisioning etc.) OKD version is free to use and includes most of the features of its commercial product, but you cannot buy a support nor you cannot use Red Hat based official images So if you need a support for Kubernetes one option would be to buy subscription for OpenShift. If you’re okay with self-support then of course there’s Kubernetes with plenty of side projects, whole ecosystem and fantastic community. For hesitant ones there’s a OKD project with almost all OpenShift features - you can later might decide to migrate to a commercial product or stick with OKD.\nWhich is better?\nIt depends on whether you’d rather pay and use support and all the features that come with a product (OpenShift) rather than project (Kubernetes, but also OKD) with self-support model.\n2. OpenShift limited installation vs. install Kubernetes (almost) anywhere If you decide to install OpenShift you need to use either\nRed Hat Enterprise Linux (RHEL) or Red Hat Atomic on OpenShift 3 Red Hat CoreOS (required by control plane - master and infra server, default for compute nodes) and optionally RHEL for compute nodes only on OpenShift 4 RHEL or CentOS for OKD. You cannot install it on other linux distributions. Kubernetes, on the other hand, can be installed almost on any linux distribution such as Debian, Ubuntu (most popular ones) and many others.\nWhen it comes to installation when choosing OpenShift you can install it on multiple platforms depending on the version:\nOpenShift 3 - manually following reference guides (yes, you need to install it using ssh, yum, vim and other old-school tools) or with openshift-ansible project. The latter is probably a better choice, but since it needs to be universal and it’s written in Ansible it’s a little bit slow, complex and hard to troubleshoot. It does come with a major feature coveted by enterprise environments - rolling-update of the whole cluster. This is a major advantage and you will probably appreciate it when you decide to upgrade your Kubernetes cluster. OpenShift 4 - has a simplified and easier to use installer that currently supports AWS and vSphere. It is performed by a dedicated Operator software and the whole configuration is kept in ConfigMaps inside a cluster (not in files on master servers like in version 3). Bare metal installations are still possible but currently they require many manual steps. Also it requires internet connections so disconnected installations are unavailable. Kubernetes on the other hand has many installation tools available (e.g. kubeadm, kube-spray, kops), some of them are better for cloud, some are more universal and complex too and it’s up to you to decide how you want to install your cluster and upgrade it (if it’s supported by the tool).\nThe last thing regarding freedom of choice for your platform are services available on major cloud platforms. Kubernetes is available on three of them - GKE on Google GCP, EKS on Amazon AWS anf AKS on Microsoft Azure. For OpenShift there’s a product called OpenShift Online, OpenShift Dedicatedand OpenShift on Azure. Additionally you can test your single node installations using the following methods:\nMinikube for Kubernetes Minishift for OKD (formerly OpenShift Origin) CDK for OpenShift Container Platform 3 CRC (CodeReady Containers) for OpenShift Container Platform 4 Which is better?\nKubernetes has become a standard and is available on more platforms than OpenShift. However, with the new, more flexible and faster installer we can expect that OpenShift will be a good alternative for Kubernetes, also in the cloud.\n3. OpenShift has more strict security policies than default Kubernetes It’s probably because of the target group for OpenShift product, but indeed default policies are more strict there than on Kubernetes. For example, most of container images available on Docker Hub won’t run on OpenShift, as it forbids to run a container as root and even many of official images don’t meet this requirement. That’s why people are sometimes confused and angry because they cannot run simple apps like they used to on Kubernetes. There’s an easy way to disable that policy, but still it shows a different approach to security.\nAlso, RBAC was an integral part of OpenShift since many releases while there are some people who use Kubernetes without RBAC security. That’s okay for a small dev/test setup, but in real life, you want to have some level of permissions - even if it’s sometimes hard to learn and comprehend (because it is at first). In OpenShift you actually don’t have a choice and you have to use it and learn it on the way as you deploy more and more apps on it.\nLast part is authentication and authorization model. There are additional mechanisms in OpenShift that makes integration with Active Directory easy, but more interesting part is authorization to external apps. As a part of OpenShift you can install additional component such as\nInternal Container Registry Logging stack based on EFK (ElasticSearch, Fluentd, Kibana) Monitoring based on Prometheus Jenkins and you use a single account to authenticate to them with OAuth mechanism (oauth-proxies running as sidecars). That makes permissions management easier and can bring additional features like in EFK where you see logs only from namespaces/projects you have access to. And yes - you can achieve the same on Kubernetes as well, but it requires a lot of work.\nWhich is better?\nDefinitely “secure by default” approach in OpenShift.\n4. OpenShift templates are less flexible than Kubernetes Helm charts For someone coming straight from Kubernetes world who used Helm and its charts, OpenShift templates as the main method of deployment whole stack of resources is just too simple. Helm charts use sophisticated templates and package versioning that OpenShift templates are missing. It makes deployment harder on OpenShift and in most cases you need some external wrappers (like I do) to make it more flexible and useful in more complex scenarios than just simple, one pod application deployments. Helm is so much better, but its current architecture (Tiller component installed as Pod with huge permissions) isn’t compatible with more strict security polices in OpenShift.\nThere are some other options available in OpenShift 3 such as Automation Broker (formerly Ansible Service Broker) or Service Catalog, but they can be installed on Kubernetes while Helm is not a (supported) option on OpenShift. Hopefully, it will change in future with version 3 of Helm where there will be no Tiller component that makes it hard to make secure. Until then when working on OpenShift you need to live somehow with those inflexible templates looking with envy on those fancy Helm charts.\nOpenShift 4 has an integrated OperatorHub which is becoming the preferred way for provisioning services (i.e. databases, queue systems). It will become eventually the best way to deploy services on OpenShift (and Kubernetes too).\nWhich is better?\nKubernetes Helm is more flexible and upcoming version 3 will make it more secure and applicable in more serious projects. However, with more operators available on OperatorHub, OpenShift 4 will gain an advantage.\n5. Routers on OpenShift vs. Ingress on Kubernetes Red Hat had needed an automated reverse proxy solution for containers running on OpenShift long before Kubernetes came up with Ingress. So now in OpenShift we have a Route objects which do almost the same job as Ingress in Kubernetes. The main difference is that routes are implemented by good, old HAproxy that can be replaced by commercial solution based on F5 BIG-IP. On Kubernetes, however, you have much more choice, as Ingress is an interface implemented by multiple servers starting from most popular nginx, traefik, AWS ELB/ALB, GCE, Kong and others including HAproxy as well.\nSo which one is better you may ask? Personally, I think HAproxy in OpenShift is much more mature, although doesn’t have as much features as some Ingress implementations. On Kubernetes however you can use different enhancements - my favorite one is an integration with cert-manager that allows you to automate management of SSL certificates. No more manual actions for issuing and renewal of certificates and additionally you can use trusted CA for free thanks to integration with Letsencrypt!\nAs an interesting fact, I want to mention that starting from OpenShift 3.10 Kubernetes Ingress objects are recognized by OpenShift and are translated/implemented by.. a router. It’s a big step towards compatibility with configuration prepared for Kubernetes that now can be launched on OpenShift without any modifications.\nWhich is better?\nBoth are great, Ingress is newer and less mature than Router, but they do a great job.\n6. A different approach to deployments Similarly like with Ingress, OpenShift chose to have a different way of managing deployments. In Kubernetes there are Deployment objects (you can also use them in OpenShift with all other Kubernetes objects as well) responsible for updating pods in a rolling update fashion and is implemented internally in controllers. OpenShift has a similar object called DeploymentConfig implemented not by controllers, but rather by sophisticated logic based on dedicated pods controlling whole process. It has some drawbacks, but also one significant advantage over Kubernetes Deployment - you can use hooks to prepare your environment for an update - e.g. by changing database schema. It’s a nifty feature that is hard to implement with Deployment (and no, InitContainers are not the same, as it’s hard to coordinate it with many instances running). Deployment, however, is better when dealing with multiple, concurrent updates - DeploymentConfig doesn’t support concurrent updates at all and in Kubernetes you can have many of them and it will manage to scale them properly.\nWhich is better?\nOpenShift DeploymentConfig has more options and support ImageStream so I’m choosing it over classic Kubernetes Deployment.\n7. Better management of container images Now this is something that I really miss in Kubernetes and personally my favourite feature of OpenShift. ImageStreams for managing container images. Do you know how “easy” it is to change a tag for an image in a container registry? Without external tools such as skopeo you need to download the whole image, change it locally and push it back. Also promoting applications by changing container tags and updating Deployment object definition is not a pleasant way to do it.\nThat’s why I love ImageStreams and here are main reasons and features:\nwith ImageStream you upload a container image once and then you manage it’s virtual tags internally in OpenShift - in one project you would always use devel tag and only change reference to it internally, on prod you would use stable or prod tag and also manage it internally in OpenShift, not dealing with registry! when using ImageStream with DeploymentConfig you can set a trigger which starts deployment when a new image appears or tag changes its reference - it’s perfect for development environments where app deploys itself whenever a new version is built (without any CICD process!) with triggers you can achieve even more - having chained builds to create an updated version of your app/tool whenever a new version of the base image is published - it’s an automated patching of all container images built from insecure images at hand! you can hide the origin of the image by exposing it as an ImageStream - e.g. one time jenkins points to a original, official image and when you wish to change something, you build your own, push it into your registry and change only reference in ImageStream, not in deployment configs like you would with traditional docker images If you’re interested in more details you might want to check my article.\nWhich is better?\nImageStreams in OpenShift are awesome!\n8. Integrated CI/CD with Jenkins Red Hat created OpenShift long before Kubernetes project was found and from the start, it was a PaaS platform. By switching from their custom solution (they used something they called gears instead of containers) to Kubernetes it became easier to bring more features and one of the most exciting is integrated Jenkins. There are multiple CI/CD software solutions available, but Jenkins is still the biggest, most universal, generic and mature solution. It is also often used with Kubernetes clusters to build container images, perform Continuous Integration tasks on them and deploy them as containers on multiple environments with Continuous Deployment pipelines. Since it’s so popular then having it as a builtin part of OpenShift makes the whole CI/CD a lot less painful. Here’s a list of my favorite features of integrated Jenkins on OpenShift:\nOAuth authentication - use your OpenShift login to log in to Jenkins and depending on the role you have on the project you get one of three jenkins role assigned (view, edit or admin). In OpenShift 4 it finally works as a Single-Sign-On (in version 3 you have to login to a service each time using the same credentials). support for source-to-image that allows you to create a custom jenkins image - a few files with plugins list, custom configuration and other resources, enable you to easily update it when a source image changes (that part also can be automated!) and use Jekins in a fully “immutable” mode two versions of template available - ephemeral for testing purposes and persistent with persistent storage for more serious job, configuration data and job history is kept separately from Jenkins itself and thus making it very easy to manage (e.g. upgrades, testing different sets of plugins) synchronization of secret object from a namespace it’s running on - different secrets are synchronized with Jenkins credentials so that username/password, ssh key or secret text are available in your jobs without ever creating them in Jenkins last but not least - pipeline definition is a separate BuildConfig object and is also defined outside of Jenkins as a OpenShift object from simple yaml file Which is better?\nOnce again an additional feature of OpenShift makes it easy to deploy your apps with CI/CD pipelines.\n9. OpenShift projects are more than Kubernetes namespaces This a minor difference, but on OpenShift there are projects which are nothing more than just Kubernetes namespaces with additional features. Besides trivial things such as description and display name (trust me - they can be helpful when you have dozens of them), projects add some default objects. Currently a few roles ( RoleBinding objects to be precise) are created alongside with a project, but you can modify default project template and use it to provision other objects. A good example would be network policies that close your project for external traffic so that is isolated and secure by default - if you want to permit some kind of traffic you would do so by creating additional policies explicitly. In a similar way you could provide default quotas or LimitRange objects and make your new projects pre-configured according to your organization rules.\nWhich is better?\nActually projects are namespaces with few features. There’s no clear winner here.\n10. OpenShift is easier for beginners As the last part I want to emphasise the difference when it comes to user experience. Containers are still new and having a complex, sophisticated interface for managing them makes it even harder to learn and adapt. That’s why I find OpenShift versions of both command line and web interfaces superior over Kubernetes ones.\nLet’s start with cli. On OpenShift there’s a oc command which is equivalent of Kubernetes’ kubectl with the following differences:\noc has support for logging to OpenShift cluster - with kubectl you need to obtain your credentials and create your kubeconfig file with some external tools oc lets you switch between projects/namespaces while kubectl doesn’t (you need exernal tools such as kubens/kubectx) - if you start working with many namespaces and clusters you will appreciate that feature, believe me oc allows you to build a container image from a source and then deploy it onto environments with a single command! ( oc new-app) It will create all required objects for you and then you may decide to export them, change and reapply or store somewhere in your repository Let’s face it - if you’re beginner then you won’t touch command line at first - you’d probably choose to play with some web interface. And after you saw this Kubernetes dashboard – overview Kubernetes dashboard – overview Kubernetes dashboard – pod list\nyou would probably be discouraged as I did when I saw it for the first time (it was a couple of years ago, but it hasn’t changed a lot unfortunately). It can be overwhelming and personally I don’t use dashboard when working with Kubernetes, as it doesn’t bring much more information than command line and you are not able to change most of the things - it’s almost like read-only panel. Let’s face it - dashboard is not a first-class citizen among many Kubernetes projects.\nNow here’s the OpenShift 3 web console: OpenShift 3 web console – startup screen OpenShift 3 web console – easy secret object management OpenShift 3 web console – pod panel with logs OpenShift 3 web console – objects editing OpenShift 3 web console – objects groups OpenShift 3 web console – single project view\nAnd the redesigned version available in OpenShift 4: OpenShift 4 web console – Grafana diagrams OpenShift 4 web console – Grafana diagrams OpenShift 4 web console – deployed operator container OpenShift 4 web console – developer catalog OpenShift 4 web console – cluster status OpenShift 4 web console – project view OpenShift 4 operators – integrated hub\nNow I’m not saying it’s the best web interface, but I consider it as one of the best features of OpenShift. First of all it has a login window, something that simple and trivial and I know it shouldn’t be a feature, but have you seen Kubernetes “login window”? Dashboard has a login window where you provide a token and honestly is confusing, especially for beginners. Most of all OpenShift web console is very useful, much more than Kubernetes dashboard. In fact, you can perform about 80% (or even 90% in OpenShift 4) of tasks directly from it - no need to launch command line or dealing with yaml objects - it can be actually a primary tool for managing OpenShift on a daily basis.\nWhich is better?\nOpenShift. Sorry Kubernetes, but people (including me!) love and need fancy web console :-)\nConclusion Some of you may think I’m a total OpenShift fanboy, but in reality, I love working with both - OpenShift and Kubernetes. After all they make it possible to deploy and manage our containerized apps in a way that was only available for unicorns like Google. So whichever you choose you’ll get tons of features making your life easier and your journey will begin towards cloud native world.\n","tags":["comparison","kubernetes","openshift"],"title":"10 most important differences between OpenShift and Kubernetes"},{"categories":["articles"],"date":"July 31, 2019","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/jenkins-on-openshift/","section":"articles","summary":"I can’t imagine deployment process of any modern application that wouldn’t be orchestrated by some kind of pipeline. It’s also the reason why I got into containers and Kubernetes/OpenShift in the first place - it enforces changes in your approach toward building and deploying but it makes up for with all these nice features that come with Kubernetes.\nOpenShift comes with Jenkins as the main orchestrator for pipelines but what I’ve noticed is that in many cases it’s used improperly. People tend to apply their old habits they’ve used for so many years on Jenkins instances running on traditional infrastructure (VMs, bare-metal) and it ends with making this even a lot messier and harder to maintain when it’s deployed in containers. It turns out that you can use Jenkins efficiently and leverage OpenShift platform features. In this article, I’m going to show you how to do it.\nWhy Jenkins Some may question the choice of Jenkins since its first version was released in 2011 and its origin project (Hudson) it has forked from, is even older - it was created in 2005. So why do we even consider this software which hasn’t been designed for containers or even cloud environments? There are a few reasons why you might want to stick with Jenkins instead of choosing other CI/CD projects or products.\n1. Myriad of plugins Indeed it was created a long time ago but thanks to it a healthy community around Jenkins project has created a myriad of plugins that help to bring more features to it. And we have support for cloud environments, containers, Kubernetes and OpenShift now - all of this provided by plugins. You can find a plugin for almost any software that is somehow related to building, testing or deployment of any framework or language. It is also the source of frustrations of many people using them. It’s because of “dependency hell” and the maintenance of it. However, with a proper approach I’m describing below it can be fairly easy mitigated - all thanks to containers.\n2. It has a nice GUI I know, it’s a silly reason but I’m going to keep repeating it anyway - not everybody is interested or have the technical knowledge to operate from command line only. The release process is often a business-oriented activity and also many non-technical people are involved in it. They will appreciate having a clear view on the whole process. Some even use a dedicated display to track each deployment. While other projects, especially the new ones such as Tekton, are designed to work with Kubernetes, they still missing a nice way to manage it from GUI.\n3. Easy to migrate There are so many new things you need to learn when working with OpenShift that at least you can use your knowledge on Jenkins. Just make sure you’re doing it right - see below for some tips.\n4. Support for shared library It is one of the underestimated features of Jenkins. The shared library offers a nice way of standardizing CI/CD pipelines by providing a versioned library with all the steps defined there. No more copy and paste - this approach can work when you’re dealing with a few apps but not when you grow rapidly. For a bigger scale, you need something better or else you’ll end up with an unmaintainable, horrific set of custom pipeline configurations.\n5. Integration with OpenShift [caption id=\u0026ldquo;attachment_1693\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;1582\u0026rdquo;] Jenkins pipeline status visible in OpenShift (OKD) web console[/caption]\nRed Hat chose Jenkins to be a CI/CD orchestrator for applications running on OpenShift and has also prepared a set of plugins to integrate it with its API. We can leverage it in the following ways:\nkeep all pipeline definitions (where to find Jenkinsfile or its content embedded directly in it) as BuildConfig native OpenShift objects rather than configuring from Jenkins. all these defined pipelines can be launched from OpenShift API (or cli - e.g. oc start-build job-name) and their progress is visible in OpenShift web console - no need to log in to Jenkins to track them synchronize Secret objects to Jenkins credentials without managing them in Jenkins directly integrated authentication and authorization enables users with view,edit and admin OpenShift roles mapped to Jenkins users. Although it is very simple (only three roles) it is also very easy and in most cases sufficient. Keeping Jenkins maintainable By combining integration features and running Jenkins as a container with external storage enables us to treat it merely as a job orchestrator without all the hassle of maintaining it. Store everything as code and let Jenkins with all its plugins do what it’s been ordered to do. And nothing more. There are some rules, however, that need to be followed to really keep it under control and avoid configuration drift. Stick to them and you will no longer fix any Jenkins instance - just relaunch it and let OpenShift do its magic.\nKeep data on a persistent volume It’s easy to implement. Just choose jenkins-persistent template to create a Jenkins instance. All history and temporary files will be kept there. In worst-case scenario when you broke something really bad you would lose only job history (and your custom jobs created outside of OpenShift but you know already it’s a bad idea). Additionally, it also makes Jenkins resilient to any types of outages - Kubernetes scheduler will keep it running on a healthy node or restart it if it becomes unresponsive.\nDefine all pipeline definitions outside of Jenkins You can play with custom jobs and create them all you want but for real production-ready pipelines use BuildConfig object. You have a choice of putting there the whole Jenkinsfile content or point to a repository where it’s kept. That also limits the usage of Freestyle jobs in Jenkins but that shouldn’t be a problem - you can always define them as a single-stage pipeline.\nUse Secrets as credentials Leverage openshift-jenkins-sync-plugin to map Secrets to Jenkins’ credentials. There are a couple of types of credentials that will be matched against Secret types with proper labels assigned to them - check the documentation in repo for more details (the official one at https://docs.openshift.com seems to be a little outdated). Oh, and I also recommend keeping this plugin up-to-date since they often fix some bugs and add more features to it. Later on I’m going to show you how.\nDon’t update plugins manually or install them at startup Plugin maintenance is the biggest problem with Jenkins which is quite easy to fix. When you need to update a particular plugin or add a new one just modify plugins.txt file kept in a repository and rebuild it. See below for more details. This also enables you to rollback a misbehaving plugin. Actually, it’s even better - you can rollback to last working instance of Jenkins keeping all the history and dependencies. In traditional downgrade process available in Jenkins, you rollback only a single plugin, not its dependencies. And please also don’t use INSTALL_PLUGINS environment variable to install plugins at startup. First of all, it takes a lot of time and, secondly, it often fails because Jenkins mirrors infrastructure often is unavailable or out of sync.\nUse code for custom modifications You may want to modify Jenkins instance and you may be tempted to do it using GUI. Don’t. Most plugins can be configured with configuration as code which is a dedicated plugin configured via yaml file. There are many examples on how to write them and the only thing you need to take care is how to provide this yaml file - include it in the image or host it externally. Whatever you choose will be far better than manual configuration.\nCreate a custom Jenkins image - step by step It’s time to create a process of building custom Jenkins images. In the following example I’m going to use Minishift but it’s also applicable to any OpenShift cluster (thanks to ImageStream abstraction layer). We will create a process that will build a new image using source-to-image builder available in OpenShift, pipeline defined in BuildConfig object and Jenkins instance to orchestrate the build process.\n1. Create a dedicated project We’re going to use a dedicated namespace (a.k.a. project in OpenShift) where it’s going to be built. Let’s call it jenkins-builder.\noc new-project jenkins-builder 2. Create a dedicated repository for Jenkins config You can reuse some of your existing repositories but I recommend creating a new one. It will become a crucial part of your CI/CD infrastructure and you should protect it. There’s my repository you can use for testing - it’s available at https://github.com/cloudowski/jenkins-openshift-pipeline and it’s public so no credentials are required.\n3. Create a Secret with git credentials If you require an ssh key to access your repo then you need to add it got the project. For example\noc create secret generic cloudowski-ssh-secret --from-file=ssh-privatekey=$HOME/.ssh/id_rsa Remember that it needs to be a private key and it cannot be encrypted (hope your private keys are protected by a passphrase).\n4. Place files in a repo with Jenkins customization The most important file is plugins.txt where you should put your additional plugins (see my sample file) and configuration. You can also put configuration files in configuration/ directory in a repo that would be copied to Jenkins home directory. In my example, I have there a configuration-as-code plugin configuration.\n5. Create a Jenkins instance We need to solve the chicken or the egg problem first. To build Jenkins we could use BuildConfig object but we want to create a process with promotion and custom, dynamic tags (they are not available for BuildConfig jobs). We’ll use jenkins-persistent template to instantiate our first Jenkins (you may use jenkins-ephemeral if you have no more PersistentVolumes available in your cluster) and add environment variables that enable overriding configuration and plugins on each startup. We’re also defining a special variable ( CASC_JENKINS_CONFIG) that points to a yaml file read by configuration-as-code plugin.\noc process -n openshift jenkins-persistent -p MEMORY_LIMIT=1024M | oc apply -f- -n jenkins-builder oc set env dc/jenkins OVERRIDE_PV_CONFIG_WITH_IMAGE_CONFIG=true OVERRIDE_PV_PLUGINS_WITH_IMAGE_PLUGINS=true CASC_JENKINS_CONFIG=/var/lib/jenkins/jenkins-casc.yaml 6. Create a BuildConfig with pipeline definition It’s time to create a BuildConfig object that would create a Jenkins pipeline job. Use the template file from my repository and apply it:\noc process -f jenkins-pipeline-template.yaml | oc apply -f- -n jenkins-builder For non-public repositories, you need to configure a git credential you created previously. The easiest way is to do it with cli\noc set build-secret --source jenkins-master YOUR-SECRET-NAME oc set build-secret --source build-image-jenkins-master YOUR-SECRET-NAME [caption id=\u0026ldquo;attachment_1694\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;1569\u0026rdquo;] Jenkins pipeline status visible in OpenShift web console[/caption]\n7. Build a new image with pipeline Start it either from Jenkins, OpenShift web console or cli\noc start-build build-image-jenkins-master [caption id=\u0026ldquo;attachment_1695\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;1583\u0026rdquo;] Pipeline building new Jenkins image[/caption]\n[caption id=\u0026ldquo;attachment_1696\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;1583\u0026rdquo;] Approval and promotion step[/caption]\n8. Use the image Now you can use the image in a new Jenkins instance or replace the one used by Jenkins which built it (kind of Inception-like trick). Once again it’s easy with cli\noc set image dc/jenkins jenkins=jenkins-builder/jenkins-master:latest --source=imagestreamtag [caption id=\u0026ldquo;attachment_1697\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;1568\u0026rdquo;] Replacing Jenkins image in DeploymentConfig object from web console[/caption] That’s it! You’ve just created a pipeline building new Jenkins container image. It’s time to use it to build great apps and deploy them on any Kubernetes or OpenShift.\n","tags":["cicd","jenkins","openshift"],"title":"Jenkins on OpenShift - how to use and customize it in a cloud-native way"},{"categories":["articles"],"date":"July 21, 2019","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/maintaining-big-kubernetes-environments-with-factories/","section":"articles","summary":"People are fascinated by containers, Kubernetes and cloud native approach for different reasons. It could be enhanced security, real portability, greater extensibility or more resilience. For me personally, and for organizations delivering software products for their customers, there is one reason that is far more important - it’s the speed they can gain. That leads straight to decreased Time To Market, so highly appreciated and coveted by the business people, and even more job satisfaction for guys building application and platforms for them.\nIt starts with code So how to speed it up? By leveraging this new technology and all the goodies that come with it. The real game-changer here is the way you can manage your platform, environments, and applications that run there. With Kubernetes based platforms you do it in a declarative manner which means you define your desired state and not particular steps leading to the implementation of it (like it’s done in imperative systems). That opens up a way to manage the whole system with code. Your primary job is to define your system state and let Kubernetes do its magic. You probably want to keep it in files in a versioned git repository (or repositories) and this article shows how you can build your platform by efficiently splitting up the code to multiple repositories.\n[caption id=\u0026ldquo;attachment_1736\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;652\u0026rdquo;] Code converted by Kubernetes to various resources[/caption]\nAreas to manage Since we can manage all the things from the code we could distinguish a few areas to delegate control over a code to different teams. Let’s consider these three areas:\n1. Platform This is a part where all platform and cluster-wide configuration are defined. It affects all environments and their security. It can also include configuration for multiple clusters (e.g. when using OpenShift’s Machine Operator or Cluster API to install and manage clusters).\nExamples of objects kept here:\nLimitRange, ResourceQuota NetworkPolicy, EgressNetworkPolicy ClusterRole, ClusterRoleBinding PersistentVolume - static pool MachineSet, Machine, MachineHealthCheck, Cluster 2. Environments (namespaces) management Here we define how particular namespaces should be configured to run applications or services and at the same time keep it secure and under control.\nExamples of objects kept here:\nConfigMap, Secret Role, RoleBinding 3. CI/CD system All other configuration that is specific to an application. Also, the pipeline definition is kept here with the details on how to build an application artifact from code, put it in a container image and push it to a container registry.\nExamples of objects kept here:\nJenkinsfile Jenkins shared library Tekton objects: Pipeline, PipelineRun, Task, ClusterTask, TaskRun, PipelineResource BuildConfig Deployment, Ingress, Service Helm Charts Kustomize overlays Note that environment-specific configuration is kept elsewhere.\nFactories Our goal here is simple - leverage containers and Kubernetes features to quickly deliver applications to production environments and keep it all as code. To do so we can delegate the management of particular areas to special entities - let’s call them factories. We can have two types of factories:\nFactory Building Environments (FBE) - responsible for maintaining objects from area 1 (platform). Factory Building Applications (FBA) - responsible for maintaining objects from area 2 (environments) and area 3 (CI/CD) Factory Building Environments First is a Factory Building Environments. In general, a single factory of this type is sufficient because it can maintain multiple environments and multiple clusters. It exists for the following main reasons:\nTo delegate control over critical objects (especially security-related) to a team of people responsible for platform stability and security To keep track of changes and protect global configuration that affects all the shared services and applications running on a cluster (or clusters) To ease management of multiple clusters and dozens (or even hundreds) of namespaces [caption id=\u0026ldquo;attachment_1737\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;763\u0026rdquo;] FBE takes care of environments and cluster configuration[/caption]\nMain tasks So what kind of tasks does this factory is responsible for? Here are the most important ones.\nBuild and maintain shared images There are a couple of container images that are used by many services inside your cluster and have a critical impact on platform security or stability. This could be in particular:\na modified Fluentd container image a base image for all your java (or other types) applications with your custom CA added to a PKI configuration on a system level similarly - a custom s2i (Source to Image) builder a customized Jenkins Image with a predefined list of plugins and even seed jobs Apply security and global configuration This is actually the biggest and most important task of this factory. It should read a dedicated repository where all the files are kept and apply it to either at a cluster level or for a particular set of environments (namespaces).\nProvide credentials In some cases, this should also be a place where some credentials are configured in environments - for example, database credentials that shouldn’t be visible by developers or stored in an application repository.\nBuild other factories Finally, this factory also builds other factories (FBA). This task includes creating new namespaces, maintaining their configuration and deploying required objects forming a new factory.\nHow to implement FBE is just a concept that can be implemented in many ways. Here’s a list of possible solutions:\nThe simplest case - a dedicated repository with restricted access, code review policy, and manual provisioning process. The previous solution can be extended with a proper hook attached to an event of merge of a pull request that will apply all changes automatically. As a part of git integration there can be a dedicated job on CI/CD server (e.g. Jenkins) that tracks a particular branch of the repo and also applies it automatically or on-demand. The last solution is the most advanced and also follows the best practices of cloud native approach. It is a dedicated operator that tracks the repository and applies it from inside a container. There could be different Custom Resources that would be responsible for different parts of configurations (e.g. configuration of namespace, global security settings of a cluster, etc.). Factory Building Applications The second type of factory is a factory building applications. It is designed to deliver applications to end-users to prod environments. It addresses the following challenges of delivery and deployment processes:\nBrings more autonomy for development teams who can use a dedicated set of namespaces for their delivery process Creates a safe place for experiments with preview environments created on-demand Ease the configuration process by reducing duplication of config files and providing default settings shared by applications and environments Enables grouping of applications/microservices under a single, manageable group of environments with shared settings and an aggregated view on deployment pipelines runs Separates configuration of Kubernetes objects from a global configuration (maintained by FBE) and application code to keep track of changes [caption id=\u0026ldquo;attachment_1738\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;749\u0026rdquo;] FBA produces applications and deploys them to multiple environments[/caption]\nMain tasks Let’s have a look at the main tasks of this factory.\nBuild and deploy applications The most important job is to build applications from a code, perform tests, put them in a container image and publish. When a new container image is ready it can be deployed to multiple environments that are managed by this factory. It is essentially the description of CI/CD tasks that are implemented here for a set of applications.\nProvide common configuration for application and services This factory should provide an easy way of creating a new environment for an application with a set of config files defining required resources (see examples of objects in area 2 and 3).\nNamespace management FBA manages two types of environments (namespaces):\npermanent environments - they are a part of CI/CD pipeline for a set of applications (or a single app) and their services preview environments - these are environments that are not a part of CI/CD pipeline but are created on-demand and used for different purposes (e.g. feature branch tests, performance tests, custom scenario tests, etc.) It creates multiple preview environments and destroys them if they are no longer needed. For permanent environments, it ensures that they have a proper configuration but never deletes them (they are special and protected).\nHow to implement Here are some implementation tips and more technical details.\nA factory can be created to maintain environments and CI/CD pipeline for a single application, however, often many applications are either developed by a single team or are a part of a single business domain and thus it is convenient to keep all the environments and processes around deployment in a single place. A factory consists of multiple namespaces, for example: FN-cicd - namespace where all build-related and delivery activities take place ( FN could be a factory name or some other prefix shared by namespaces managed by it) FN-test, FN-stage, FN-prod - permanent environments various number of preview environments Main tasks can be implemented by Jenkins running inside FN-cicd namespace and can be defined either by independent Jenkinsfiles or with jobs defined in a shared library configured on a Jenkins instance. In OpenShift it’s even easier, as you can use BuildConfig objects of Pipeline type which will create proper jobs inside a Jenkins instance. A dedicated operator seems to be again the best solution. It could be implemented as the same operator which maintains FBE with a set of Custom Resources for managing namespaces, pipelines and so on. Summary A couple of years ago, before docker and containers, I was a huge fan of Infrastructure as Code. With Kubernetes, operators, and thanks to its declarative nature, it is now possible to manage all the aspects of application building process, deployment, management of environments it would run in and even whole clusters deployed across multiple datacenters or clouds. Now it’s becoming increasingly important how are you handling the management of the code responsible for maintaining it. The idea of using multiple factories is helpful for organizations with many teams and applications and allows easy scaling of both and keeping it manageable at the same time.\n","tags":["cicd","containers","kubernetes","openshift"],"title":"Maintaining big Kubernetes environments with factories"},{"categories":["articles"],"date":"June 20, 2019","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/honest-review-of-openshift-4/","section":"articles","summary":"We waited over 7 months for OpenShift Container Platform 4 release. We even got version 4.1 directly because Red Hat decided not to release version 4.0. And when it was finally released we almost got a new product. It’s a result and implication of acquisition of CoreOS by Red Hat announced at the beginning of 2018. I believe that most of the new features in OpenShift 4 come from the hands of a new army of developers from CoreOS and their approach to building innovative platforms. But is it really that good? Let me go through the most interesting features and also things that are not as good as we’d expect from over 7-month development (OpenShift 3.11 was released in October 2018).\nIf ain’t broke, don’t fix it Most parts of OpenShift haven’t changed or changed very little. In my comparison of OpenShift and Kubernetes I’ve pointed out the most interesting features of it and there are also a few remarks on version 4. To make it short here’s my personal list of the best features of OpenShift that just stayed at the same good level comparing to version 3:\nIntegrated Jenkins - makes it easy to build, test and deploy your containerized apps BuildConfig objects used to create container images - with Source-To-Image (s2i) it is very simple and easy to maintain ImageStreams as an abstraction level that eases the pain of upgrading or moving images between registries (e.g. automatic updates) Tightened security rules with SCC that disallows running containers as root user. Although it’s a painful experience at first this is definitely a good way of increasing overall security level. Monitoring handled by the best monitoring software dedicated to container environments - Prometheus Built-in OAuth support for services such as Prometheus, Kibana and others. Unified way of managing your users, roles and permissions is something you’ll appreciate when you start to manage access for dozens of users Obviously, we can also leverage Kubernetes features remembering that some of them are not supported by Red Hat and you’ll be on your own with any problems they may cause.\nThe best features I’ll start with features I consider to be the best and sometimes revolutionary, especially when comparing it to other Kubernetes-based platforms or even previous version 3 of OpenShift.\nNew flexible and very fast installer This is huge and probably one of the best features. If you’ve ever worked with Ansible installer available in version 3, then you’d be pleasantly surprised or even relieved you don’t need to touch it ever again. Its code was messy, upgrades were painful and often even small changes took a long time (sometimes resulting in failures at the end) to apply. Now it’s something far better. Not only because it uses Terraform underneath (the best tool available for this purpose) for managing, is faster and more predictable, but also it’s easier to operate. Because the whole installation is performed by a dedicated operator all you need to do is provide a fairly short yaml file with necessary details. Here’s the whole file that is sufficient to install a multi-node cluster on AWS:\napiVersion: v1 baseDomain: example.com compute: - hyperthreading: Enabled name: worker replicas: 3 platform: aws: rootVolume: size: 50 type: gp2 type: t3.large replicas: 2 controlPlane: hyperthreading: Enabled name: master platform: aws: rootVolume: size: 50 type: gp2 type: t3.xlarge replicas: 3 metadata: creationTimestamp: null name: ocp4demo networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineCIDR: 10.0.0.0/16 networkType: OpenShiftSDN serviceNetwork: - 172.30.0.0/16 platform: aws: region: us-east-1 pullSecret: \u0026#39;{\u0026#34;auths\u0026#34;:{\u0026#34;cloud.openshift.com\u0026#34;:{\u0026#34;auth\u0026#34;:\u0026#34;REDACTED\u0026#34;,\u0026#34;email\u0026#34;:\u0026#34;tomasz@example.com\u0026#34;}}}\u0026#39; sshKey: | ssh-rsa REDACTED tomasz@example.com The second and yet more interesting thing about the installer is that it uses Red Hat Enterprise Linux CoreOS (RHCOS) as a base operating system. The biggest difference from classic Red Hat Enterprise Linux (RHEL) is how it’s configured and maintained. While RHEL is a traditional system you operate manually with ssh and Linux commands (sometimes they are executed by config management tools such as Ansible), RHCOS is configured with Ignite (custom bootstrap and config tool developed by CoreOS) at the start and shouldn’t be configured in any other way. That basically allows to create a platform that follows an immutable infrastructure principle - all nodes (except control plane with master components) can be treated as ephemeral entities and just like pods can be quickly replaced with fresh instances.\nUnified way of managing nodes Red Hat introduced a new API for node management. It’s called “Machine API” and is mostly based on Kubernetes Cluster API project. This is a game changer when it comes to provisioning of nodes. With MachineSets you can distribute easily your nodes among different availability zones but also you can manage multiple node pools (just like in GKE I reviewed some time ago with different settings (e.g. pool for testing, pool for machine learning with GPU attached). Management of the nodes has never been that easy! For me, that’s a game changer and I predict it’s going to be also a game changer for Red Hat. With this new flexible way of provisioning alongside with RHCOS as default system, OpenShift becomes very competitive to Kubernetes services available on major cloud providers (GKE,EKS,AKS).\nRapid cluster autoscaling Thanks to the previous feature we can finally scale our cluster in a very easy and automated fashion. OpenShift delivers cluster autoscaling operator that can adjust the size of your cluster by provisioning or destroying nodes. With RHCOS it is done very quickly which is a huge improvement over the manual, error-prone process used in the previous version of OpenShift and RHEL nodes. Not only does it work on AWS but also on-premise installation based on VMware vSphere. Hopefully, soon it will be possible on most major cloud providers and maybe on non-cloud environments as well (spoiler alert - it will, see below for more details). We missed this elasticity feature and finally it minimizes the gap between those who are lucky (or simply prefer) to use cloud and those who for some reasons choose to build it using their own hardware.\nGood parts you’ll appreciate New nice-looking web console that is very practical This is the most visible for end-user and it looks like it was completely rewritten, better designed, good looking piece of software. We’ve seen a part of it in version 3 responsible for cluster maintenance but now it’s a single interface for both operations and developers. Cluster administrators will appreciate friendly dashboards where you can check cluster health, leverage tighter integration with Prometheus monitoring to observe workloads running on it. Although many buttons open a simple editor with yaml template in it, it is still the best web interface available for managing your containers, their configuration, external access or deploying a new app without any yaml. OpenShift 4 web console – project view OpenShift 4 web console – cluster status OpenShift 4 web console – pod view OpenShift 4 web console – developer catalog OpenShift 4 web console – nodes view\nRed Hat also prepared a centralized dashboard ( https://cloud.redhat.com) for managing all your OpenShift clusters. It’s quite simple at the moment but I think it’s an early version of it.\nOh, they also got rid of one annoying thing - now you finally log in once and leverage Single Sign-On feature to access external services i.e. Prometheus, Grafana and Kibana dashboards, Jenkins and others that you can configure with OAuth.\nOperators for cluster maintenance and as first-class citizens for your services Operator pattern leverage Kubernetes API and promises “to put operational knowledge into software” which for end-user brings an easy way for deploying and maintaining complex services. It’s not a big surprise that in OpenShift almost everything is configured and maintained by operators. After all, this concept was born in CoreOS and has brought us the level of automation we could only dream of. In fact, Red Hat deprecated its previous attempt to automate everything with Ansible Service Broker and Service Catalog. Now operators handle most of the tasks such as cluster installation, its upgrades, ingress and registry provisioning, and many, many more. No more Ansible - just feed these operators with proper yaml files and wait for the results. At the same time, Red Hat created a website with operators ( https://www.operatorhub.io/) and embedded it inside OpenShift. They say it will grow and you’ll be able to find there many services that are very easy to use. Actually, during the writing of this article, the number of operators available on OperatorHub has doubled and it will grow and become stable (some of them didn’t work for me or required additional manual steps). For any interested in providing their software as operator there is operator-framework project that helps to build it ( operator-sdk), run it and maintain it (with Operator Lifecycle Manager). In fact, you can start even without knowing how to write in golang, as it provides a way to create an operator using Ansible (and converts Helm Charts too). With some small shortcomings, it’s the fastest way to try this new way of writing kubernetes-native applications. OpenShift 4 operators – integrated hub OpenShift 4 operators – operator overview OpenShift 4 operators – components OpenShift 4 operators – subscriptions\nIn short - operators can be treated as a way of providing services in your own environment similarly to the ones available on public cloud providers (e.g. managed database, kafka cluster, redis cluster etc.) with a major difference - you have control over the software that provides those services and you can build them on your own (become a producer) while on cloud you are just a consumer.\nI think that essentially aligns perfectly with open source spirit that started an earlier revolution - Linux operating system that is the building block for most of the systems running today.\nCluster configuration kept as API objects that ease its maintenance Forget about configuration files kept somewhere on the servers. They cause too many problems with maintenance and are just too old-school for modern systems. It’s time for “everything-as-code” approach. In OpenShift 4 every component is configured with Custom Resources (CR) that are processed by ubiquitous operators. No more painful upgrades and synchronization among multiple nodes and no more configuration drift. You’re going to appreciate how easy now maintenance has become. Here are the short list of operators that configure cluster components that were previously maintained in a rather cumbersome way (i.e. different files provisioned by ansible or manually):\nAPI server (feature gates and options) Nodes via Machine API (see above for more details) Ingress Internal DNS Logging (EFK) and Monitoring (Prometheus) Sample applications Networking Internal Registry OAuth (and authentication in general) And many more.. [caption id=\u0026ldquo;attachment_1765\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;1151\u0026rdquo;] Global configuration handled by operators and managed with yaml files kept inside a control plane[/caption]\nNow all these things are maintained from code that is (or rather should be) versioned, audited and reviewed for changes. Some people call it GitOps, I myself call it “Everything as Code” or to put it simply - the way it should be managed from the beginning.\nBad parts (or not good enough yet) Nothing is perfect, even OpenShift. I’ve found a few things that I consider to be less enjoyable than previous features. I suspect and hope they will improve in future releases, but at the time of writing (OpenShift 4.1) they spoil this overall picture of it.\nLimited support for fully automatic installation Biggest disappointments of it - list of supported platform that leverages automatic installation. Here it is:\nAWS VMware vSphere Quite short, isn’t it? It means that when you want to install it on your own machines you need to have vSphere. If you don’t then be prepared for a less flexible install process that involves many manual steps and is much, much slower. It also implies another flaw - without a supported platform, you won’t be able to use cluster autoscaling or even manual scaling of machines. It will be all left for you to manage manually.\nThis makes OpenShift 4 usable only on AWS an vSphere. Although it could work anywhere, it is a less flexible option with a limited set of features. Red Hat promises to extend the list of supported platforms in future releases (Azure,GCP and OpenStack is coming in version 4.2) - there are already existing implementation also for bare metal installations so hopefully, this will be covered as well.\nYou cannot perform disconnected installations Some organizations have very tight security rules that cut out most of the external traffic. In previous version, you would use a disconnected installation that could be performed offline without any access to the internet. Now OpenShift requires access to Red Hat resources during installation - they collect anonymized data (Telemetry) and provide a simple dashboard from which you can control your clusters. They promise to fix it in upcoming version 4.2 so please be patient.\nIstio is still in Tech Preview and you can’t use it in your prod yet I’m not sure about you but many organizations (and individuals like me) have been waiting for this particular feature. We’ve had enough of watching demos, listening to how Istio is the best service mesh and how many problems it will address. Give us stable (and in case of Red Hat also supported) version of Istio! According to published roadmap It was supposed to be available already in version 4.0 but it wasn’t released so we obviously expected it to be GA in 4.1. For many, this is one of the main reasons to consider OpenShift as enterprise container platform for their systems. I sympathize with all of you and hope this year we’re all going to move Istio from test systems to production. Fingers crossed!\nCDK/Minishift options missing makes testing harder I know it’s going to be fixed soon but at the moment the only way of testing OpenShift 4 is either use it as a service (OpenShift Online, Azure Red Hat OpenShift) or install it which takes roughly 30 minutes. For version 3 we have Container Development Kit (or its open source equivalent for OKD - minishift) which launches a single node VM with Openshift and it does it in a few minutes. It’s perfect for testing also as a part of CI/CD pipeline. Certainly, it’s not the most coveted feature but since many crucial parts have changed since version 3 it would be good to have a more convenient way of getting to know it.\nUPDATED on 30.8.2019 - there is a working solution for single node OpenShift cluster. It is provided by a new project called CodeReady Containers and it works pretty well.\nVery bad and disappointing Now this is a short “list” but I just have to mention it since it’s been a very frustrating feature of OpenShift 3 that just happened to be a part of version 4 too.\nSingle SDN option without support for egress policy I still can’t believe how the networking part has been neglected. Let me start with a simple choice or rather lack of it. In version 3 we could choose Calico as an SDN provider alongside with OpenShift “native” SDN based on Open vSwitch (overlay network spanned over software VXLAN ). Now we have only this single native implementation but I guess we could live with it if it was improved. However, it’s not. In fact when deploying your awesome apps on you freshly installed cluster you may want to secure your traffic with NetworkPolicy acting as Kubernetes network firewall. You even have a nice guide for creating ingress rules and sure, they work as they should. If you want to limit egress traffic you can’t leverage egress part of NetworkPolicy, as for some reason OpenShift still uses its dedicated “EgressNetworkPolicy” API which has the following drawbacks:\nYou should create a single object for an entire namespace with all the rules - although many can be created, only one is actually used (in a non-deterministic way, you’ve been warned) - no internal merge is being done as it is with standard, Kubernetes NetworkPolicy objects You can limit only traffic based on IP CIDR ranges or DNS names but without specifying ports (sic!) - that’s right, it’s like a ‘80s firewall appliance operating on L3 only… [caption id=\u0026ldquo;attachment_1766\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;1152\u0026rdquo;] OpenShift web interface for managing NetworkPolicy is currently simple web yaml editor with some built-in tips on how to write them[/caption] I said it - for me, it’s the worst part of OpenShift that makes the management of network traffic harder. I hope it will be fixed pretty soon and for now Istio could potentially fix it on an upper layer. Oh wait, it’s not supported yet..\nSummary Was it worth waiting for OpenShift 4? Yes, I think it was. It has some flaws that soon are going to be fixed and it’s still the best platform for Kubernetes workloads that comes with support. I consider this version as an important milestone for Red Hat and its customers looking for a solution to build a highly automated platform - especially when they want to do it on their own hardware, with full control and freedom of choice. Now with operator pattern so closely integrated and promoted, it starts to look like a really good alternative to the public cloud, something that was promised by OpenStack and it looks like it’s going to be delivered by Kubernetes with OpenShift\n","tags":["kubernetes","openshift"],"title":"Honest review of OpenShift 4"},{"categories":["pl"],"date":"June 3, 2019","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/pl/czas-introwertykow/","section":"pl","summary":"Jestem introwertykiem. Jak wielu ludzi w IT. Często słyszę dowcip - “nie chcesz rozmawiać z ludźmi to idź na studia informatyczne” i chyba panuje takie ogólne przeświadczenie, że w branży IT jest nas najwięcej. Jest to jednak dalekie od prawdy, gdyż według wielu badań rozkład wychodzi mniej więcej po równo t.j. cechy introwertyczne i ekstrawertyczne rozkładają się równomiernie po całej populacji. I od razu obalmy pierwszy mit - nie jest prawdą, że się jest albo introwertykiem albo ekstrawertykiem. Ta cecha to spektrum - można być super-introwertykiem skrywającym się w samym sobie i można też być gdzieś po środku bliżej ekstrawertyka. Wówczas często określa się taką osobę jako ambiwertyka.\nCzym jest ten introwertyzm? Nie chcę tutaj przytaczać naukowych teorii - te łatwo znaleźć w sieci (np. wikipedia). Napiszę to z mojej własnej perspektywy i własnymi słowami. Otóż jest to cecha, która określa w jakich sytuacjach gromadzisz energię a w jakich ją zużywasz. Dla nas introwertyków magazynujemy ją przebywając samotnie lub w bardzo małej grupie osób. I samotnie wcale nie oznacza na odosobnieniu. Chodzi bardziej o mentalnym przebywaniu z samym sobą, z własnymi myślami, odczuciami i refleksjami. Kierujemy uwagę do siebie - stąd określenie intro wertyk. Jak już ją zgromadzimy to możemy ją spożytkować na - uwaga - przebywanie z innymi, wdawać się w konwersacje i inne aktywności w grupie. Jestem żywym przykładem, że introwertyk może również występować publicznie czy prowadzić kilkudniowe szkolenia dla grupy osób, której wcześniej nie znał.\nEkstrawertycy mają lepiej? Nawet introwertycy lubią ekstrawertyków. W końcu są to osoby, które często brylują w tłumie, często przewodzą zabawie, są duszą towarzystwa. Jako stworzenia socjalne potrzebujemy przynależności, powiązania z innymi i stąd wydaje nam się, że im większa grupa tym lepiej dla nas. Jak się okazuje nie dla wszystkich. Introwertycy również lubią grupy, ale mniejsze. I do tego nie do końca odpowiada im tzw. “small talk” i wolą poważniejsze rozmowy niż zaledwie płytką wymianę słów. Niestety nasza kultura preferuje ekstrawertyczne zachowania. W końcu lepiej sprzedaje się kolejny show z celebrytami niż coś mniej wystrzałowego o głębszym przekazie. Wydaje się też nam, że tylko będąc osobą wystrzałową da się osiągnąć sukces. To jednak wielkie kłamstwo - w końcu introwertyczni ludzie sukcesu (i nie tylko) unikają rozgłosu i płytkich rozmów skupiając się na rzeczach ważniejszych.\nRewolucja informacyjna i nowy porządek Wprowadzenie nowych technologii wywróciło dotychczasowy porządek. Odkąd otworzyły się nowe środki komunikacji i dzielenia się informacjami, obecna przewaga ekstrawertyków w udziale i kształtowaniu naszego świata. Introwertycy stoją w dużej mierze za tymi technologiami oraz jest ona dla nich sposobem na wyrażanie siebie. W końcu komunikacja mailowa pozwala przemyśleć co chcemy przekazać i sformułować lepiej nasze myśli przed faktycznym jej przekazaniem. Faktem jest, że takie sieci społecznościowe jak Instagram czy Facebook są opanowane w głównej mierze przez ekstrawertyczne osoby (część o dość narcystycznym usposobieniu i wykorzystujący je do budowania swojej własnej wartości na “lajkach”), ale czy wiesz kto zbudował te wszystkie wspaniałe portale? Tak, to w dużej mierze robota introwertyków. Ludzie, którzy często spędzają dużo czasu na rozmyślaniu, ale też na projektowaniu i tworzeniu nowej, wirtualnej rzeczywistości. Twórca Facebooka Mark Zuckeberk, twórca Microsoft Bill Gates czy też Linus Torvalds jako twórca Linuksa będącego fundamentem tworu znanego dzisiaj jako chmura publiczna. Oni wszyscy są introwertykami i stoją za jedynymi z największych rewolucji w świecie IT i nie tylko.\nObalamy mity o introwertykach Poniżej kilka mitów krążących w społeczeństwie i będącego w sumie przykładem jak zachowania ekstrawertyczne są preferowane, a te introwertyczne kojarzone z cechami negatywnymi (podobnie jak inne, “odbiegające” od średniej jak niski wzrost, waga itp.).\nIntrowertycy zawsze siedzą przed komputerami i boją się ludzi Kiedyś książki, a teraz komputery stały się ucieczką od ludzi, ale nie tylko dla introwertyków. I nie jest prawdą, że introwertycy wolą komputery. To fakt - komputery są bardziej przewidywalne, nie posiadają emocji i jeśli nie działają to dość sprawnie da się je naprawić lub wymienić. Niemniej introwertycy również łakną kontaktów z ludźmi, ale przede wszystkim czują się lepiej w mniejszym gronie zaufanych przyjaciół. Wielkie bankiety to nie jest ich naturalne środowisko co nie oznacza, że nie potrafią się na nich odnaleźć. Z reguły będą starać się znaleźć mniejsze grono, w którym będą mogli prowadzić głębsze rozmowy niż tylko te na temat pogody. Szczególnie jeśli znajdą osoby znajome - zawieranie nowych znajomości trwa u nas po prostu dłużej.\nIntrowertycy nie umieją sprzedawać Bzdura. Jeśli rozumiesz przez sprzedaż pewnego rodzaju akwizycję, tzw. “cold calling” czy też inne formy poszukiwania szybkiego kontaktu i natychmiastowego “zamknięcia” procesu to pewnie tak - niektórzy ekstrawertycy potrafią czarować i dokonać takich rzeczy. Doskonale opisuje to Daniel Pink w książce “To sell is human” (polski tytuł to “Jak być dobrym sprzedawcą” - moim zdaniem zupełnie nietrafione i przeinaczające intencję autora tłumaczenie tytułu), gdzie pokazuje, że osoby gdzieś pośrodku spektrum sprawdzają się najlepiej - są to wspomniani na początku ambiwertycy. Osobiście uważam, że dzisiaj sprzedażą może zająć się każdy. Obawiasz się kontaktu z innymi? Zawsze możesz schować to za automatem jak np. aukcja internetowa czy sklep z fajnym opisem. Nie jesteś super przebojowy, ale umiesz rozmawiać w małym gronie? To jak najbardziej możesz sprzedawać usługi i produkty. Jesteśmy przesyceni bzdurami i sztuczkami wyciągniętymi wprost z podręczników sprzedaży sprzed kilkudziesięciu lat. Ludzie autentyczni i empatyczny są w stanie osiągnąć o wiele więcej na dłuższą metę niż naśladowcy tych wspomnianych wzorców akwizycji.\nIntrowertycy to samotnicy z wyboru To podobnie jak powiedzieć, że ekstrawertycy to ludzie żyjący tylko od imprezy do imprezy. Prawda jest taka, że ekstrawertycy ładują swoje “baterie” pośród ludzi, a energię tą zużywają będąc w małym gronie lub też samotnie. Introwertycy z kolei czerpią ją z przebywania z samym sobą i wykorzystują do wyjścia na zewnątrz, do większej grupy gdzie również nawiązują znajomości i prowadzą normalne życie towarzyskie. Nie jest ono pewnie w takiej skali i intensywności jak w przypadku ekstrawertyków i z pewnością nie zobaczysz wielu zdjęć na Instagramie, ale nie jest to w żadnym wypadku samotność.\nWystąpienia publiczne to domena ekstrawertyków Skoro ładujemy te swoje baterie to występy publiczne mogą być tym miejscem, gdzie ta energia może być spożytkowana. I tak się dzieje chociażby w moim wypadku - chęć dzielenia się wiedzą, doświadczenia i inspirowania innych jest silniejsza oraz na tyle motywujące, że wyjście na scenę wygrywa z potrzebą poprzebywania z samym sobą. Nawet jeśli początki są trudne to jest to coś czego da się nauczyć niezależnie od typu osobowości. Możliwe, że ekstrawertycy mają ku temu lepsze predyspozycje (nie mam tego jak sprawdzić empirycznie niestety) to niekoniecznie wszyscy posiadają chęci rozwoju w tym kierunku.\nIntrowertyzm da się zmienić - trzeba więcej imprezować Potrzeba zmiany swoich cech i postępowania jest istotnie możliwa, ale do pewnego stopnia. To z czym przychodzimy na świat jest częścią nas i jeśli w całości tego nie zaakceptujemy to staniemy się klientami wszelkiego rodzaju pseudo-coachów i programów rozwoju (piszę to jako osoba, które przeczytała sporo książek tego typu i uczestniczyła w paru warsztatach). Możesz się nauczyć technik, przełamywać naturalny strach i dążyć do swoich celów, ale twoje główne cechy będą zbliżone do tego co dostałeś, a nie tego kim chciałbyś być. Ten idealny obraz tworzony przez media kreuje ekstrawertyzm jako pożądaną cechę jakby to było podobne do bycia fit, gdzie kształtowanie ciała jest również ograniczone przez twoje predyspozycje. Nie, nie zamienisz się w ekstrawertyka więcej imprezując, ale najwięcej uzyskasz wykorzystując to wszystko co jest z tym masz “w zestawie”.\nJak sprawdzić czy jestem introwertykiem? Najprościej wybrać jeden z testów dostępnych za darmo w sieci. Może to być test 16 osobowości (znany też jako test Myersa-Briggsa) - na przykład ten.\nWykorzystaj swój czas Nigdy nie było introwertykom tak łatwo pozostać sobą wykorzystując dzisiejszą technikę i swobodę jednocześnie osiągając swoje osobiste cele. Pomimo, że w społeczeństwie żywy jest obraz idealnej osoby ekstrawertycznej to warto iść swoją drogą. Nawet jeśli będzie to droga w mniejszym gronie, ale ludzi z którymi warto ją przemierzać.\n","tags":["introwertyzm"],"title":"Czas introwertyków"},{"categories":["articles"],"date":"May 26, 2019","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/how-to-increase-container-security-with-proper-images/","section":"articles","summary":"Security is a major factor when it comes to a decision of whether to invest your precious time and resources in new technology. It’s no different for containers and Kubernetes. I’ve heard a lot of concerns around it and decided to write about the most important factors that have the biggest impact on the security of systems based on containers running on Kubernetes.\nThis is particularly important, as it’s often the only impediment blocking potential implementation of container-based environment and also taking away chances for speeding up innovation. That’s when I decided to help all of you who wants strengthen security of their containers images.\nImage size (and content) matters The first factor is the size of a container image. It’s also a reason why container gained so much popularity - whole solutions, often quite complex are now consisting of multiple containers running from images available publicly on the web (mostly from Docker hub) that you can run in a few minutes.\nIn case your application running inside a container gets compromised and the attacker gets access to an environment with a shell, he needs to use his own tools and often it’s the first thing he does - he downloads them on the host. What if he can’t access tools that will enable him to do so? No scp, curl, wget, python or whatever he could use. That would make things harder or even impossible to make harm to your systems.\nThat is exactly why you need to keep your container images small and provide libraries and binaries that are really essential and used by the process running in a container.\nRecommended practices Use slim versions for base images Since you want to keep your images small choose “fit” versions of base images. They are often called slim images and have less utils included. For example - the most popular base image is Debian and it’s standard version debian:jessie weights 50MB while debian:jessie-slim only 30MB. Besides less exciting doc files (list available here) it’s missing the following binaries\n/bin/ip /bin/ping /bin/ping6 /bin/ss /sbin/bridge /sbin/rtacct /sbin/rtmon /sbin/tc /usr/bin/lnstat /usr/bin/nstat /usr/bin/routef /usr/bin/routel /usr/sbin/arpd They are mostly useful for network troubleshooting and I doubt if ping is a deadly weapon. Still, the less binaries are present, the less potential files are available for an attacker that might use some kind of zero-day exploits in them.\nUnfortunately, neither official Ubuntu nor CentOS don’t have slim versions. Looks like Debian is a much better choice, it contains maybe too many files but it’s very easy to fix - see below.\nDelete unnecessary files Do you need to install any packages from a running container? If you answered yes then you probably doing it wrong. Container images follow a simple unix philosophy - they should do one thing (and do it well) which is run a single app or service. Container images are immutable and thus any software should be installed during a container image build. Afterward, you don’t need it and you can disable it by deleting binaries used for that.\nFor Debian just put the following somewhere at the end of your Dockerfile\nRUN rm /usr/bin/apt-* /usr/bin/dpkg* Did you know that even without binaries you may still perform actions by using system calls? You can use any language interpreter like python, ruby or perl. It turns out that even slim version of Debian contains perl! Unless your app is developed in perl you can and should delete it\nRUN /usr/bin/perl* For other base images you may want to delete the following file categories:\nPackage management tools: yum, rpm, dpkg, apt\nAny language interpreter that is unused by your app: ruby, perl, python, etc.\nUtilities that can be used to download remote content: wget, curl, http, scp, rsync\nNetwork connectivity tools: ssh, telnet, rsh\nSeparate building from embedding For languages that need compiling (e.g. java, golang) it’s better to decouple building application artifact from building a container image. If you use the same image for building and running your container, it will be very large as development tools have many dependencies and not only they will enlarge your final image but also download binaries that could be used by an attacker.\nIf you’re migrating your app to container environment you probably already have some kind of CI/CD process or at least you build your artifacts on Jenkins or other server. You can leverage this existing process and add a step that will copy the artifact into the app image.\nFor full container-only build you can use multistage build feature. Notice however that it works only with newer version of Docker (17.05 and above) and it doesn’t work with OpenShift. On OpenShift there is similar feature called chained builds, but it’s more complicated to use.\nConsider the development of statically compiled apps Want to have the most secure container image? Put a single file in it. That’s it. Currently, the easiest way to accomplish that is by developing it in golang. Easier said than done, but consider it for your future projects and also prefer vendors that are able to deliver software written in go. As long it doesn’t compromise quality and other factors (e.g. delivery time, cost) it definitely increases security.\nMaintaining secure images There are three types of container images you use:\nBase images Services (a.k.a. COTS - Common off-the-shelf) Your applications Base images aren’t used to run containers - they provide the first layer with all necessary files and utilities\nFor services you don’t need to build anything - you just run them and provide your configuration and a place to store data.\nApplication images are built by you and thus require a base image on top of which you build your final image.\n[caption id=\u0026ldquo;attachment_1700\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;351\u0026rdquo;] Container image types[/caption]\nOf course, both services and applications are built on top of a base image and thus their security depends largely depends on its quality.\nWe can distinguish the following factors that have the biggest impact on container image security:\nThe time it takes to publish a new image with fixes for vulnerabilities found in its packages (binaries, libraries) Existence of a dedicated security team that tracks vulnerabilities and publish advisories Support for automatic scanning tools which often needs access to security database with published fixes Proven track of handling major vulnerabilities in the past In a case where there are many applications built in an organization, an intermediary image is built and maintained that is used as a base image for all the applications. It is used to primarily to provide common settings, additional files (e.g. company’s certificate authority) or tighten security. In other words - it is used to standardize and enforce security in all applications used throughout the organization.\n[caption id=\u0026ldquo;attachment_1701\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;476\u0026rdquo;] Use of intermediary images[/caption]\nNow we know how important it is to choose a secure base image. However, for service images, we rely on a choice made by a vendor or an image creator. Sometimes they publish multiple editions of the image. In most cases it is based on some Debian/Ubuntu and additionally on Alpine (like redis, RabbitMQ, Postgres).\nDoubts around Alpine And what about alpine? Personally, I’m not convinced it’s a good idea to use it in production. I mean there are many unexpected and strange behaviors and I just don’t find it good enough for a reliable, production environment. Lack of security advisories, a single repo maintained by a single person is not the best recommendation. I know that many have trusted this tiny, Linux distribution that is supposed to be “Small. Simple. Secure.”. I’m using it for many demos, training and testing but still, it hasn’t convinced me to be as good as good old Debian, Ubuntu, CentOS or maybe even\nOraclelinux.\nAnd just recently they had a major vulnerability discovered - an empty password for user root was set in most of their images. Check if your images use the affected version and fix it ASAP.\nRecommended practices Trust but verify As I mentioned before there sometimes official images don’t offer the best quality and that’s why it’s better to verify them as a part of CI/CD pipeline.\nHere are some tools you should consider:\nAnchore (opensource and commercial)\nClair (opensource)\nOpenscap (opensource)\nTwistlock (commercial)\njFrog Xray (commercial)\nAquasec (commercial)\nUse them wisely, also to check your currently running containers - often critical vulnerabilities are found and waiting for next deployment can cause a serious security risk.\nUse vendor-provided images For service images, it is recommended to use images provided by a vendor. They are available as so-called “official images”. The main advantage is that not only they are updated when a vulnerability is found in the software but also in an underlying OS layer. Think twice before choosing a non-official image or building one yourself. It’s just a waste of your time. If you really need to customize beyond providing configuration, you have at least two ways to achieve it:\nFor smaller changer you can override entrypoint with your script that modifies some small parts; script itself can be mounted from a configmap.\nHere’s a Kubernetes snippet of a spec for a sample nginx service with a script mounted from nginx-entrypoint ConfigMap\nspec: containers: - name: mynginx image: mynginx:1.0 command: [\u0026#34;/ep/entrypoint.sh\u0026#34;] volumeMounts: - name: entrypoint-volume mountPath: /ep/ volumes: - name: entrypoint-volume configMap: name: nginx-entrypoint For bigger changes, you may want to create your image based on the official one and rebuild it when a new version is released\nUse good quality base images Most official images available on Docker Hub are based on Debian. I even did a small research on this a couple of years ago (it is available here) and for some reason, Ubuntu is not the most popular distribution. So if you like Debian you can feel safe and join the others who also chose it. It’s a distribution with a mature ecosystem around\nIf you prefer rpm-based systems (or for some reasons your software requires it) then I would avoid CentOS and consider Red Hat Enterprise Linux images. With RHEL 8, Red Hat released Universal Base Image (UBI) that can be used freely without any fees. I just trust more those guys, as they invest a lot of resources in containers recently and these new UBI images should be updated frequently by their security team.\nAvoid building custom base images Just don’t. Unless your paranoia level is close to extreme, you can reuse images like Debian, Ubuntu or UBI described earlier. On the other hand, if you’re really paranoid I don’t think you trust anyone, including guys who brought us containers and Kubernetes as well.\nAuto-rebuild application and intermediary images when vulnerabilities are found in a base image In the old, legacy vm-based world the process of fixing vulnerabilities found in a system is called patching. Similar practice takes place in container-based world but in its specific form. Instead of fixing it on the fly, you need to replace the whole image with your app. The best way to achieve it is by creating an automated process that will rebuild it and even trigger a deployment. I found OpenShift ImageStreams feature to address this problem in the best way (details can be found in my article), but it’s not available on vanilla Kubernetes.\nConclusion We switched from fairly static virtual machines to dynamic, ephemeral containers with the same challenges - how to keep them secure. In this part, we have covered the steps required to address them on the container image level. I always say that container technology enforces the new way of handling things we used to accomplish in rather manual (e.g. golden images, vm templates), error-prone processes. When migrating to containers you need to embrace an automatic and declarative style of managing your environments, including security-related activities. Leverage that to tighten security of your systems starting with basics - choosing and maintaining your container images.\n","tags":["containers","kubernetes","openshift","security"],"title":"How to increase container security with proper images"},{"categories":["articles"],"date":"January 21, 2019","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/three-levels-of-highly-available-apps-on-kubernetes/","section":"articles","summary":"Beautiful but useless systems Hundreds of applications, thousands of users and millions of requests - that is often a landscape of a modern IT environment. However, problems are still the same. One of the most important is how to achieve high availability of your service. After all you’ve been crafting all those microservices with beautiful architecture, bounded contexts and newest frameworks so that the world could admire and use it. That won’t happen if you don’t provide proper level of availability. Even the most brilliant and sophisticated system is useless when it’s rarely available.\nIn this article I’m focusing on application side and how to achieve the best results with proper approach, configuration and processes. Kubernetes itself has a pretty simple architecture and control plane (master servers) are easy to set up in HA cluster. Although there are interesting topics in it as well I’m not going to elaborate on them now.\nThe best investment You should be aware that the less your service is available the more problems you have. In the first place you lose money when your paying customers cannot use it. However this is not the biggest issue here. Eventually you are able to bring it back to live, but every time your service fails it decreases your credibility. Customers and business partners start to perceive your company as less reliable and eventually you may lose not only your current business, but also future opportunities.\nAnd so one of the best investment decisions is the one that would increase availability of your service. That’s where containers come to rescue with their built-in capabilities making high availability as easy as never before.\nCloud Native approach to high availability Kubernetes is a project founded by Google and is based on their experiences of running millions containers with thousands applications for many years. It’s for sure a good example and a reliable source of best practices that we can all apply today in our environments. We must however embrace the new way of delivering applications - perform it in a Cloud Native way. There are a couple of elements of this approach that are essential to application resilience. The most important one is ephemerality.\nEphemeral components of container environment Containers are ephemeral by design and this definitely makes things easier. You cannot restart them, but only start new ones from immutable container image. Since it’s working that way by design no one should care if there was some data written by particular container instance. All data and configuration must be decoupled from container. Kubernetes keeps configuration in ConfigMap and Secret objects while data is kept on PersistentVolumes. So whenever container crashes for some reason, a new one is created and all data is delivered to it regardless of the node it’s been launched on. And that’s where it gets even more interesting. When using containers with Kubernetes all non-master nodes are treated as ephemeral too! You can remove, add new ones or replace in case of any failures without all those tricky and often proprietary cluster solutions.\nThree levels With containers running on Kubernetes we can distinguish three levels of high availability. They are available for every applications running inside a container and in most cases you can rely on default configuration which provides a reasonable level reliability.\nLevel 1 - Pod Application in Kubernetes runs inside Pods which are composed of one or more containers and they are nothing more than just a special processes. These processes can sometimes crash for various reasons that are just hard to predict. Sometimes they crash because of badly written software, other times it’s just unexplainable and hard to trace event that occurs at random times.\n[caption id=\u0026ldquo;attachment_1724\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;960\u0026rdquo;] Container restart inside a Pod[/caption]\nBy default these processes are restarted automatically fixing those intermittent problems for you.\nKubernetes also assumes that when a process is running it means your app is working properly. However often it’s not true and while process may exists your app could actually send a malformed replies to users or even don’t send any at all. That’s why there’s a livenessProbe that can be defined for each container to not only restart them in case of crash, but also perform periodic active checks with one of these three methods:\nExecAction - execute script inside a container TCPSocketAction - check whether a TCP port is open HTTPGetAction - check an HTTP code returned by GET method performed on specified URL - the best choice for web applications By using them your container will be protected from not only unexpected crashes, but also from upcoming ones with proactive restarts based on results of these checks.\nSo even on this basic level Kubernetes keeps your containers running and with a little effort you can tune it to get even more reliability.\nHow to increase availability on a pod level To set your availability levels higher you should consider the following:\nDefine a livenessProbe for each container. Use proper method. Avoid ExecAction when your container can process HTTP requests. Set proper initialDelaySeconds parameter to give your app some time to initialize (especially for ones based on JVM like Spring Boot - they are slow to start their HTTP endpoints) For web apps use HTTPGetAction and make sure your app can inform Kubernetes whether it works only using http code (this type doesn’t check content of the reply). It is recommended to use standard url for all apps e.g. /healthz. Make sure that you check only state of your apps and not underlying services such as database. To decrease time needed for recovery you should also make your container images small so that on cold start (i.e. node starts a pod from an app image for the first time) to minimize a time required to download the image. It is mostly visible in big environments where network bandwidth is a precious resource and there are hundreds of different containers running - then every additional 10MB of container image size can make a huge difference. Level 2 - Node Second level of resilience is assured by multi-node architecture and scalability features of Kubernetes.\nLet’s start with the simplest scenario where an app is running as a single instance in one pod. When a node that was running it crashes, the new pod is created by Kubernetes on other, available and healthy node that meets its requirements (cpu/mem reservations, taints, affinities etc.). In that way Kubernetes recovers from node crashes even for those singe-instance apps. Of course this is a rare case since most workload are running in multiple instances spread across multiple nodes. With Kubernetes features such as affinity settings you can request scheduler to assign a node for each application in a way that would minimize impact of node crash - only a small number of them would have to be recreated.\nMulti-instance app running on different nodes\nOn cloud environments you can leverage multiple availability zones to make your cluster resilient even to a failure of the whole data center. What is more interesting is that by default Kubernetes scheduler will try to spread your pods across available those failure domains. All you need to do is to make sure you place your nodes in multiple zones.\n[caption id=\u0026ldquo;attachment_1725\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;960\u0026rdquo;] Crash of a node affects only a part of app[/caption][caption id=\u0026ldquo;attachment_1728\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;960\u0026rdquo;] Pod being recreated on a healthy node[/caption]\nAnd that’s how you can mitigate crashes of a node, multiple nodes or even whole data centers!\nHow to increase availability on a node level These are recommended practices you should apply to your config on a Node level:\nFor non-cloud environments you can leverage automatic distribution of pods across your failure domains by assigning proper labels to nodes - use failure-domain.beta.kubernetes.io/zone as key and arbitrary, unique keys for each failure domain. Never launch your app directly from a Pod - it won’t survive a crash of a node. Even for single pod applications use ReplicaSet or Deployment objects, as they manage pods across whole cluster and maintain specified number of instances (even if it’s only one). Use affinity configuration with custom rules to spread your pods based on your environments architecture, especially when you run Kubernetes on non-cloud environments. For example you could define multiple failure domains based on server type, rack, server room and data center. Level 3 - Multiple Clusters Last level can add even more nines to your availability SLO. You can achieve it by deploying your apps on multiple clusters. It is quite easy with Kubernetes since a recipe for your app is simple:\nrunning app = container image (1) + configuration (2) + objects definition (3) + data (4) (1) is kept in container registries that can be replicated as a part of CI/CD.\n(2) and (3) are similar - they are kept in git repository (often it is an independent service e.g. GitHub) and all you to do is to upload them also inside CI/CD pipeline.\nThe last part (4) is more problematic, but it concerns only a small part of most workloads. Since all previous parts are in-place, you need to take care of raw data and there are plenty of methods you can use to synchronize data between different clusters (i.e. rsync, block-level snapshots). There aren’t ready solutions to that problem yet, but I believe they will come up either from community or as enterprise, commercial products.\n[caption id=\u0026ldquo;attachment_1729\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;960\u0026rdquo;] Sample hybrid solution based on multi-cloud with a deployment controlled by CI/CD pipeline[/caption]\nYou can create multiple clusters in the cloud using one or many providers. When using single provider you can leverage its services to mitigate data migration issues - for example by using Database-as-a-Service for databases with additional geo-replication options, copying snapshots of underlying PersistentVolumes between regions and many more.\nFor multi-cloud or hybrid solutions you can gain not only higher level of availability, but also more freedom and independency. This latter byproduct is often a Holy Grail for those looking for a real escape from vendor lock-in.\nThis last level is the most exciting, opening a lot of possibilities, but also the most challenging.\nHow to increase availability on a cluster level To fully leverage availability features on this highest level you need to prepare your environment in many areas. Here are the most significant and relevant ones:\nData - that’s the biggest challenge here and you should focus on finding a solution to that. For your stateful applications you should consider using technology that provides solid replication. You may want to check Rook, as it provides a fully automated (or Cloud Native) way for deploying storage nodes inside Kubernetes cluster. For components like container registries you should find a service that have built-in replication already - I recommend checking Harbor. Design your CI/CD accordingly. It should orchestrate deployments to all clusters using the same container images. You can use any CI/CD orchestrator and I can recommend Jenkins with its huge amount of plugins to all kinds of cloud providers or actually any software that exists today. Use pipelines as code and for big projects I highly advise using shared libraries - it’s the best combination so far despite having some drawbacks (e.g. lack of good testing tools for pipeline code, somewhat painful development process). Control end-user traffic to your clusters with DNS. That’s the easies way and you should pick a right solutions. In worst case you can stick with static dnd entries and in case of failure or maintenance you could change it manually. For bigger and better solution use more sophisticated dns services such as Route53 or similar. They have health checks and complex routing engines that you may find handy. Summary Let’s be clear here - you can’t reach 100% level of availability - no one can, even Google (see their error budget approach). Nevertheless, if you wish to improve your level of service, containers running on Kubernetes is currently the best way to achieve it. Improve resilience with the same, common approach regardless of technology you chose to create them, and do it as easy as never before.\nGood luck and may your service never crash!\n","tags":["cloud-native","containers","high-availability","kubernetes","openshift"],"title":"Three levels of highly available apps on Kubernetes"},{"categories":["articles"],"date":"October 8, 2018","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/shamans-in-organizations/","section":"articles","summary":"Imagine for a while that your organization is like a village where there are regular residents and shamans who keep most of the knowledge for themselves. This is a story about them and why it is dangerous, how to manage it and prevent from reaching your goals and causing harm to other residents.\nWho are shamans? Very often shamans are elders in the village which means that they’ve worked very long in the organization. They have broad knowledge of various aspects of it - starting from technology being used, frameworks, languages (often no longer in use in modern environments) and specific implementations, workarounds and other. They acquired it often with hard work, but this expertise comes naturally when working a long time in a particular area.\nDifferent needs of shamans, village and its residents These people feel a strong need to be shamans and use their tricks every day - especially during a crisis. They do it because they like (as we all do) feel important and respected. Unfortunately, other residents (i.e. employees with less experience and practice) are the ones who keep them important - they go to shamans looking for help, use their services, knowledge and maintain their status. The situation gets complicated and worse when a shaman is away or busy performing his magic tricks (or is not in a good mood) - village and its residents are on shaman’s mercy waiting for his return. This seriously impacts the life of all and causes many problems.\nWhy shamans hide their knowledge? It’s simple - they think that by doing so they are able to maintain high status. This, however, is a very risky game and in the long term doesn’t bring much benefits for them.\nIs knowledge still treasure which should be guarded? Nowadays when we have google in our pockets (smartphones) keeping knowledge to ourselves is just silly and doesn’t make sense. Of course, sometimes it is not that easily available, because of a specific implementation of particular technology, some history behind it (those “quick” fixes and small adjustments) and other, organization-specific matters. History shows these kinds of non-standard, custom solutions are often replaced by standardized ones which are easier and cheaper to maintain. And what’s even more important these new solutions come with external support. That’s right my dear shamans - your village may decide to hire shamans from the neigboring village!\nEnd of asymmetry - there’s something more valuable than knowledge This shamanic approach is getting increasingly stigmatised, as it significantly slows down development of a village and not all residents like (or rather they don’t have a choice actually) to use shaman’s services. It’s dictated by the market and by the fact that we live in (ironically) a “global village” where we have easy access to a myriad of services.\nViva skills! It’s not knowledge that is coveted and appreciated, but skills. You can acquire knowledge very fast, faster than ever before, but only skills can put it in a good use in particular cases and they are much more valuable. With so many tools, new technologies it’s very important to use them accordingly to specific needs and circumstances, but also taking under considerations other factors (e.g. cost effectiveness). Having those skills is just more appreciated by the village, as it brings more value and visible benefits.\nDevelopment assisted with “magic” A village is a whole ecosystem of connections, but we know from history that putting some group higher than other, because of their origin, skin color or knowledge, often led to revolution. We definitely disapprove situation where someone wants to gain more at the cost of us often justifying it by his alleged privileging. The truth is that any of us can become a shaman (or rather achieve this level of expertise) - “10 thousand hours rule” clearly shows how. It’s our innate need to develop ourselves and become better at what we do. And that’s much easier to achieve with help from others. This is the role of the elders in the village - shortening the path to mastery and removing obstacles that are not visible for inexperienced. That’s just simply better and faster path to prosperity of a village and its residents.\nShaman’s new tasks What is left for those who possess great knowledge and pass it to others - should they wait for someone to outgrow them and confirm their biggest fear that they will no longer be needed in the village (and maybe even banished eventually)?\nWell, their main objective is not only to perform day-to-day activities, keeping things working, but also pushing it forward by looking for new opportunities, learning about them and also teaching others. Mastery is a never-ending road and is even more challenging now with so dynamic development and fast-changing world.\nBut are skills really that important?\nInstead of shamanism we need something else There was always something more important than technology, knowledge and all those magic tricks. And it has become even more crucial nowadays in the age of “I’ll google it”. It’s universal values such as dependability, honesty and responsibility. It’s the most precious currency of our modern world - you cannot buy those values or pretend. At the same time, they are the foundations of good societies and organizations. There will always be people who know more, but knowledge is just simple to get. It’s much, much harder to find people with not only expertise but also have proper values. Such people build good organizations, great culture, team spirit and attracts others with similar traits.\nEnd of magic - there comes a time of wise men It’s time to put an end to magic tricks, hiding knowledge, relying self-esteem and position on it in your company. In a long-term it’s going to impair everyone - starting from shamans, regular employees depending on them, but also the whole organization. Only real wise men have a chance for real respect and high status they’ve been seeking for.\nDon’t be like a shaman - stop using your spells and become a wise man!\n","tags":["devops","knowledge"],"title":"Shamans in organizations - who are they and why are they dangerous"},{"categories":["articles"],"date":"September 15, 2018","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/why-managing-container-images-on-openshift-is-better-than-on-kubernetes/","section":"articles","summary":"So you’ve decided to go with Kubernetes and started building your container images. Now the question is where to push them and how to manage them properly? It’s something that you don’t see on these “always working demos” and slides. You will have to deal with it sooner or later and it might be a real challenge. After all, both Kubernetes and OpenShift are build around the concept of container images that are instantiated in many containers with different configurations and settings.\nKubernetes transparent approach to container images Let’s start with Kubernetes and its way of dealing with container images. It follows a simple unix philosophy - particular components do one thing and do it well. Putting them together (e.g. pods templates in Deployment with access exposed using Service based on labels) make it so powerful. This simplicity has some drawbacks though. Containers are created from container images and are referenced in different resources. For example here is a sample Pod definition for a single container based on foo:1.0 image.\napiVersion: v1 kind: Pod metadata: name: foo spec: containers: - image: foo:1.0 name: foo One thing is clear here - this image has to exist already and Kubernetes needs to have an access to the origin registry. So the big question is - Why can’t we create images in the same way as we create pods, replicasets and other resources? And the answer is simple - there is no resource in Kubernetes responsible for building container image (yet?). That’s the missing piece in my opinion and is confusing a bit. So how do most people mamnage to build container images on Kubernetes? In the easiest, but definitely not the most secure and flexible way - just plain Docker with some tricks.\n“Good”, old Docker There are a couple of choices you have when you want to build container images for Kubernetes. In general there are two ways:\nBuild images outside Kubernetes using external tools, scripts, and other magic Build images inside Kubernetes using some combination of its resources In almost all scenarios you will end up with our old friend - docker build command. Although there are many other options (e.g. buildah) I suppose people will continue to use it for a long time.\nOne major issue with that approach (especially implemented inside Kubernetes) is that you need to expose docker socket (or use tcp connection) directly to build agent (e.g. Jenkins) which is a huge security risk - this agent will be able to do anything with other containers running on the same host. Yes, I know there are many ways to make it more secure, but most people do it that way. Sad, but true (and insecure).\n[caption id=\u0026ldquo;attachment_1771\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;1068\u0026rdquo;] Example workflow with Jenkins accessing Docker directly[/caption]\nOpenShift with Kubernetes approach If you’re new to OpenShift or you’ve come from Kubernetes world you might be tempted to follow the same approach. Fortunately, default restricted policy assigned to all new pods will prevent you from launching your Jenkins container with host’s docker socket mounted inside. You may try to change it, enforce it somehow, but a better approach is just sit down and ask yourself - Do I really want to expose my containers to danger just to build a container image? The only right answer is NO. Now it’s time to use something better and more secure.\nBuilding and managing images with BuildConfig and ImageStream Welcome to a better world with declarative resources for building container images ( BuildConfig) and abstraction layer for them ( ImageStream). Let’s start with BuildConfig first. It’s a resource that defines a way to build a container image and push it somewhere. Here’s an example definition:\napiVersion: v1 kind: BuildConfig metadata: name: foo-build spec: source: git: uri: \u0026#34;git@git.example.com:foo.git\u0026#34; type: Git strategy: dockerStrategy: noCache: true output: to: kind: ImageStreamTag name: foo:latest That’s it - now you just need to create that object like you would with similar yaml definitions (e.g. oc apply -f foo-buildconfig.yaml). This will create a new foo-build object that when started will do the following things:\nfetch files from git repository build a container image based on Dockerfile definition from that repo (in this example it would have to be in root directory) push foo:latest built image to ImageStreamTag object (single instance of ImageStream pointing to one image) in current namespace It is possible to push it directly to docker registry, but it would be such a waste of features that ImageStream provides. So where does this image goes? That’s the point - it’s not important from your perspective. It’s an abstraction layer and you shouldn’t really care what happens with it (by default it will be pushed to OpenShift internal registry). What you should care is how it may help you and believe me - it has many interesting features.\nIt’s worth to mention that BuildConfig object is really powerful and lets you build container images quite easy for the following reasons:\nIt can use Source-To-Image to build an application without any Dockerfile involved, it autodetects technology/framework and chooses appropriate builder image for you It can use Dockerfiles (as in the example above), but it launches a dedicated pod that controls the whole process - you don’t give access to all container running on the host like you would with Jenkins+Docker on Kubernetes It can download code from private repo and uses Secret objects for authentication It can push built image directly into private container image registry also using authentication stored in a Secret It can trigger other builds to create a chain of dependent builds - perfect solution when you have a base image and other dependant ones that need to be rebuilt automatically ImageStream as a very useful abstraction layer OpenShift introduced a concept of ImageStream. So what is it? The simplest definition would be a collection of references to real container images. You can also imagine that ImageStream is like a directory (from a unix world) with a symlinks (ImageStreamTags) in it. These symlinks points to actual container images. Just like directory and symlinks they do not contain real data. ImageStreamTags store only container images metadata.\n[caption id=\u0026ldquo;attachment_1772\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;936\u0026rdquo;] ImageStream with ImageStreamTags[/caption]\nImporting images to ImageStream ImageStreamTags objects are references to individual container images kept in internal or external registries. They are identified by immutable sha256 ids, as tag can always change, but sha256 checksum can’t.\n[caption id=\u0026ldquo;attachment_1773\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;1328\u0026rdquo;] ImageStreamTags with references to container images[/caption]\nYou can import those external images and reference them in a DeploymentConfig resource definition rather than specifying it’s origin directly. External images can be also imported into an internal registry to speed up deployments - otherwise, they will be directly downloaded from remote registry. And this import process can be done automatically by OpenShift if configured properly.\n[caption id=\u0026ldquo;attachment_1776\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;1188\u0026rdquo;] Importing images to ImageStream[/caption]\nHiding and replacing container images Interesting feature of ImageStream is the one that allows it to hide real image that’s behind this ImageStream. For example, at first you decide to use official nginx image (of course provided you don’t like the one provided by OpenShift and you’ll adjust your scc policy) as nginx ImageStream. All your apps will use it for static content in their deployments definitions. However when you decide to change something that is specific for your organization you build a new image and replace a reference in ImageStream. Then each new app will use it in a totally transparent way without changing anything!\n[caption id=\u0026ldquo;attachment_1775\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;1310\u0026rdquo;] Abstraction of foo with ImageStream[/caption]\nMagic with triggers Now that’s when things are getting really interesting. In OpenShift you can attach triggers to some objects (i.e. BuildConfig, DeploymentConfig) on some events. That what’s making it so powerful and fully automated. Let’s have a look at two real-life examples.\nKeeping your deployment always up-to-date So you have your nginx, rabbitmq or any other image you use with your own configuration. How about keeping it up-to-date without any manual action? Not sure about you, but for automation freak like me it sounds perfect. All you need to do is provide the following option to your DeploymentConfig definition:\ntriggers: - type: ImageChange imageChangeParams: from: kind: ImageStreamTag name: \u0026#39;foo:latest\u0026#39; namespace: openshift Then you need to make sure your foo:latest ImageStream is set for scheduled imports - you can set it with cli\noc import-image foo --scheduled and it’s ready!\nNow when a new image is discovered, it will trigger a new deployment using that new image.\nAll the best features of ImageStream in an example, real-world scenario Image a scenario when you want to upgrade all images of your app not because the code has changed, but because a base image that it’s been built on top of has been updated i.e. an important security bug has been fixed.\n[caption id=\u0026ldquo;attachment_1774\u0026rdquo; align=\u0026ldquo;alignnone\u0026rdquo; width=\u0026ldquo;1564\u0026rdquo;] Complete workflow of automated deployment triggered by base image change[/caption] So what we have here is a fully automated workflow that consists of the following steps:\nNew container image is being imported from the external registry (preferably as scheduled import set on the jdk8 ImageStream) ImageStream jdk8 triggers a new build of an app defined in foo BuildConfig Build fetches app code from git repo, builds a new container image and publishes it in app’s foo ImageStream New container image is pushed into the internal registry and ImageStreamTag reference changes and points to that new image This action triggers a new deployment on a foo DeploymentConfig object Within a couple of minutes, you have your app running on an updated version of the image without touching anything! And that’s my favorite feature of OpenShift ImageStream. I wish I had something similar in Kubernetes, as playing with Docker directly is so not “cloud native” :-)\n","tags":["containers","images","kubernetes","openshift"],"title":"Why managing container images on OpenShift is better than on Kubernetes"},{"categories":["pl"],"date":"August 2, 2018","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/pl/hamulce-innowacji-w-polsce/","section":"pl","summary":"Lepiej nie było nigdy Podobno żyjemy w najbezpieczniejszych czasach - brak wojen od kilkudziesięciu lat, brak poważniejszych epidemii, względny spokój i dobrobyt. Byli, są i będą ciągle narzekający - ważne jednak nie dać się wciągnąć w ten wir czarnowidztwa (polskie “z kim się zadajesz, takim się stajesz” lub naukowe podejścia dotyczące średniej z 5 ludzi ciebie otaczających).\nJednocześnie te dobrodziejstwa przybliżyły wszystkim (no dobra - wszystkim z dostępem do jakiegokolwiek komputera i internetu, czyli ~80-90% ludzi w Polsce?) dostęp do wiedzy. Teraz jak nigdy wystarczy chcieć. Chcieć i zacząć działać. Nigdy nie było to prostsze, naprawdę!\nI mamy rok 2018, a ja mam wrażenie, że w dużej części organizacji, niezależnie czy sektora publicznego czy prywatnego, wciąż niewiele się zmieniło. No dobra - są fajniejsze komputery niż 10 czy 15 lat temu, są fajniejsze narzędzia, szybszy internet (zdjęcia z Pudelka ładują się szybciej i to pewnie w 4K!). Baaa - wielu ludzi posiadło wiedzę na temat wprowadzania nowych metod usprawniających organizację pracy - wszechobecny Scrum, standupy, Kanbany i Leany.\nHamulce Zatem co obecnie blokuje innowację w dziedzinie IT w Polsce? Co powoduje, że część ludzi wybiera karierę na zachodzie nie widząc perspektyw rozwoju w kraju? Oto co według mnie jest głównymi hamulcami.\nStara gwardia, stare przyzwyczajenia Poprzez “stare” nie mam na myśli wieku. Są ludzie młodsi ode mnie, którzy osiągnęli naprawdę wiele, ciągle się rozwijają, widzą potrzebę usprawniania, posiadają energię i ciężko pracują. Są też ludzie blisko emerytury, którzy mimo, że ich młodość przypadła na czasy, gdy telewizor kolorowy był czymś “na wypasie” to i tak są w stanie zauważyć zmiany, a dzięki swojemu doświadczeniu odróżnić co jest ważne, a co nie. Z drugiej strony znam takich, którzy niezależnie od wieku tkwią w miejscu, w swoich przekonaniach, niezmienności i niemalże są dumni z tego.\nI nie - to nie jest tak, że kiedyś to były lepsze, mniej zawodne samochody, jedzenie zdrowsze, a ludzie bardziej życzliwi. Psychologia to wyjaśnia (np. tutaj), ale dla mnie jest to po prostu ucieczka i kolejna próba usprawiedliwiania. Szukania wymówek, lenistwa itp. Dla odmiany jedne z najbardziej wartościowych książek powstały faktycznie dawno (chociażby “Medytacje” Marka Aureliusza), a co za tym idzie były dostępne dla wielu ludzi podobnie jak dostęp do technologii dzisiaj..\nStrach i perfekcjonizm Ileż to razy słyszałem przy wprowadzaniu zmiany, że powinniśmy wziąć pod uwagę to i tamto, aby zrobić to raz a dobrze. Jasne - jak byśmy budowali most, dom to ok, ale nie przy IT! Tutaj zwinność jest dodawana do nazwy każdego nowego produktu (kurcze - może niektórzy nie sprawdzili co oznacza “Agile”?) jest absurdem. Nie zmieni tego wprowadzenie Scruma, “wdrożenie DevOpsa” czy migracja aplikacji na mikroserwisy. To zakamuflowany perfekcjonizm tkwiący w nas, wpajany od przedszkola, utrwalany w szkołach i egzekwowany w organizacjach. Bo jak popełnisz błąd to najwidoczniej jesteś niedostatecznie dobry (“w końcu nie po to ci tyle płacimy w tym IT?”). A co powie jeszcze szef twojego szefa? A co jeśli dojdzie to do kierownictwa z dalekiego kraju? Musi być dobrze. Od razu. I najgorsze, że sami nawzajem to w sobie utrwalamy prześcigając się w znajdowaniu wad rozwiązań - kto więcej ten lepszy. Przyznaję się, że sam nauczony przez lata również często łapię się na uczestnictwo w tej rywalizacji. Smutne, ale prawdziwe. Dlatego o ile jestem wielkim zwolennikiem metod zwinnych i metody małych kroków to nie wierzę, że jest to do osiągnięcia bez zmiany sposobu myślenia - wszakże nawet realizując małe części większego projektu możemy być ograniczeni myśleniem o doprowadzeniu wszystkiego na raz przez uwagę na potencjalną krytykę.\nBrak zaufania Podstawa budowania dobrych zespołów (przynajmniej według Patricka Lencioniego i jego “Pięć dysfunkcji pracy zespołu”) to zaufanie. Jak możesz powierzyć komuś w pełni zadanie jednocześnie pilnując go za każdym razem, sprawdzając i mikrozarządzając? Nie możesz, tylko udajesz i w dużej mierze wykorzystujesz tylko swoją pozycję w uwielbianej przez polaków hierarchii służbowej. Być może to wciąż zalegające w podświadomości naszych dziadków i rodziców przyzwyczajenia z epoki, gdzie ostrożność była cnotą ze względu na opresyjny charakter ustroju, w którym przyszło im żyć. Nie mi tu dochodzić przyczyn, ale fakt jest taki, że wciąż zbyt często doświadczam ograniczonego lub zupełnego braku zaufania. To jest coś czego wciąż się musimy nauczyć, bo nie możemy zmienić tego co było, ale z pewnością mamy wpływ na to co będzie.\nNadzieja Na szczęście spotykam też grupy osób, które nauczone (same, przez dobre otoczenie lub na bazie doświadczeń i refleksji) innego sposobu myślenia i działania. To z nimi właśnie warto “góry przenosić”, pchać do przodu i jednocześnie zmagać się wspólnie z tymi, których wartości takie są dalekie oraz jakże obce. Oby więcej tych pierwszych niż tych drugich na naszej zawodowej (i nie tylko) ścieżce!\n","tags":["innowacja","refleksje"],"title":"Hamulce innowacji w Polsce"},{"categories":["pl"],"date":"June 20, 2018","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/pl/dlaczego-utworzylem-kurs-kubernetes/","section":"pl","summary":"Udostępniam właśnie pierwsze odcinki mojego kursu z Kubernetes. A tutaj opisuję dlaczego to robię.\nCzym jest kurs Kubernetes Kurs Kubernetes po polsku jest darmowym kursem online w postaci krótkich filmików produkowanych przeze mnie i publikowanych cyklicznie w sieci. Omawiam w nim najważniejsze, konkretne i praktyczne informacje o działaniu orkiestratora kontenerów - Kubernetes.\nKurs ten NIE jest szczegółowym szkoleniem, materiałem referencyjnym (choć dokładam wszelkich starań mogą się pojawić błędy i nieścisłości), ani też produktem.\nDlaczego uważam, że należy poznać Kubernetes Według mnie jest to jeden z najważniejszych projektów ostatnich lat w obszarze zwinnego dostarczania oprogramowania. Od lat obserwuję co się dzieje na rynku, przeżyłem wirtualizację, chmury prywatne i publiczne, ale to kontenery wraz z Kubernetes uważam za kamień milowy w tej dziedzinie. Wiąże się to z nowymi możliwościami samych kontenerów, ale też z koniecznością zmiany podejścia do budowania aplikacji i jej utrzymania. Jako fan automatyzacji nie mogę przejść obok tak wspaniałego rozwiązania, gdzie w sposób w pełni deklaratywny można zarządzać całością procesu zgodnie z koncepcjami Infrastructure as Code i pełnego Continuous Deployment.\nPotencjalnie jest to coś co może przynieść największe korzyści wszystkim tym, którym bliskie jest zwinne podejście nie tylko do tworzenia oprogramowanie, ale też do jego zarządzania od momentu, gdy z kodu powstaje deployowalny (wgrywalny?) artefakt i trafia na elastyczne i wydajne środowisko produkcyjne.\nA co z cloud? Byłem świadkiem, gdzie dużo firm rzuciło się na chmurę prywatną. Niestety w większości przypadków, które znam kończyło się inną wersją wirtualizacji bez niezbędnej zmiany podejścia to tworzenia maszyn z osadzoną w niej aplikacją i w elastyczny sposób zarządzania nią. Podobnie często chmura publiczna staje się kolejnym datacenter tyle, że bez własnych serwerów. Do tego sami dostawcy chmur (AWS, Azure, Google) dostarczają Kubernetes jako usługi, a wymagana wiedza jest wspólna dla wszystkich instalacji, niezależnie od wybranej infrastruktury.\nKto powinien się temu przyjrzeć bliżej Kurs adresuję do technicznego grona naszej społeczności IT w Polsce. W szczególności dla wszystkich odpowiadających za dowożenie aplikacji na środowiska produkcyjne jak i późniejsze ich utrzymanie - od deweloperów z zacięciem admina przez inżynierów DevOps aż po klasycznych administratorów/sysopsów.\nZachęcam również do spojrzenia na to od strony architektury osobom, które kodu już nie dotykają - wiedza taka przyda się z pewnością jak w końcu kontenery dotrą również do Twojej organizacji.\nDlaczego po polsku? Jest dużo materiałów w sieci po angielsku, ale uważam, że część rzeczy łatwiej zrozumieć w języku, którym posługujemy się na codzień.\nForma wideo, a nie tekst Nagrania są krótkie i pokazuję w nich jak to naprawdę wszystko działa. Uważam, że nie wszyscy odpalą swoje środowiska, ale nagranie pomoże zrozumieć istotę działania większej ilości osób demonstrując nowe metody pracy i spostrzec jakie to jest takie łatwe oraz dostępne od zaraz.\nPrawda leży głębiej Przyczyna, dla której utworzyłem kurs jest bardziej złożona. Składają się na nią dwie rzeczy, w które głęboko wierzę.\nPierwsza to moje przekonanie, iż dobre oprogramowanie potrzebuje jeszcze lepszego środowiska. Wytworzenie aplikacji nie kończy się na zbudowaniu jara czy innej paczki. Baa - ono nie kończy się nawet na zbudowaniu kontenera z tą aplikacją. Do tego potrzeba czegoś więcej - odpowiedniej wiedzy wspartej konkretnymi działaniami. Nie ma nic bardziej frustrującego niż niedziałająca (lub działająca z przerwami) aplikacja - nieważne jak pięknie wyglądająca lub zaprojektowana.\nI dochodzimy do drugiej ważnej dla mnie rzeczy. Według wielu rankingów Polacy są w czołówce programistów na świecie. Zgodnie z pierwszym założeniem potrzebne jest coś więcej niż dobry kod. Dlatego też chciałbym przyczynić się do poprawy choćby małym stopniu do ulepszenia procesów dostarczania i utrzymywania takich środowisk. Wierzę, że mój kurs jak i samo Kubernetes jest w stanie znacząco przyczynić się do ulepszenia sposobu dostarczania i utrzymywania dobrych środowisk dla nowoczesnych aplikacji.\nZa darmo? Tak. Mój kurs jest i będzie całkowicie za darmo - liczę, że dzięki temu wzrośnie liczba ekspertów, a skorzysta na tym sporo firm oraz przed wszystkim ludzi chcących poznać nowoczesne technologie.\nKurs dostępny jest tutaj. Zapraszam!\n","tags":["edu","kubernetes","kurs","pl"],"title":"Dlaczego utworzyłem kurs Kubernetes po polsku"},{"categories":["articles"],"date":"March 11, 2018","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/three-qos-classes-in-kubernetes/","section":"articles","summary":"One of the features that comes with Kubernetes is its ability to scale horizontally services running on it and use available resources more efficiently. I’ve been hearing that containers are just lightweight virtualization (which is not true) so you can put more apps on the same resources. I can agree that it’s partially true - for some type of workloads containers can use less resources because of Kubernetes scheduler and linux kernel magic :-)\nTwo-level scheduling When you launch a pod in Kubernetes a really nice and sophisticated piece of software called scheduler determines which host should be chosen to run it. It does its magic by taking into consideration many factors and it’s also highly configurable. Like I said - it’s pretty cool and if you want to find out more please watch this video.\nSo when your pod finally launches on a host it is under its control. To make it clear we need to understand one, simple principle:\nContainers are just processes\nYes, they are more fancy, but still are treated like processes by the kernel on the node they’re running. It means that after they have been chosen by Kubernetes scheduler their fate is in hands of linux kernel. It’s behaviour can be controlled with proper parameters passed from Kubernetes to container runtime (e.g. docker-engine).\nNot everyone is equal When it comes to access to precious resources such as compute power and memory there is a constant fight between all running processes on particular host - including the ones running in host namespace (non-containerized) and also in each container. Linux kernel has many features for handling processes. For cpu it has many schedulers, process priorities (statically assigned by administrator using nice command, dynamic internally assigned by kernel) and many more. Memory management is even more complex. Actually most of kernel code is about memory, but only when Google presented cgroups we could start limiting process memory (hard rss limits defined in limits.conf weren’t actually respected…). With cgroups we received many, many more things of which two are used by containers:\ncpu controller for cpu prioritization and limiting mem controller for memory reservation and limiting Thanks to these features we can run nginx with memory limited to 128M and half a core of cpu:\ndocker run -m 128M -c 0.5 nginx What does it have to do with Kubernetes?\nThree QoS classes When deploying a pod you can specify two values for both cpu and mem resources:\nresources: limits: cpu: 200m memory: 1G requests: cpu: 500m memory: 1G Request can be treated as reservations (or soft limits) while limits are just hard limits which cannot be exceeded. What is important is that these values are optional and depending how you set them your pod will be assigned to one of three classes:\nGuaranteed - if you set only limits OR if you set limits and requests to the same value Burstable - if you set only requests OR if you set requests lower than limits Best-effort - if you don’t set those at all Why should I care about what class my pod is assigned to? There are a couple of reasons why you should consider specifying resources values.\n1. Pod will be assigned to a default class If you don’t specify resources your pod will be assigned to Best-Effort class (unless your namespace has been configured in a special way - see below). And yes - that’s the worst, less prioritized class.\n2. Class determines how your pod is treated when host is running low on resources Depending on resource type - cpu or memory - bad things may happen, sometimes even a murder (of a process)!\nFor cpu its excess power will be distributed proportionally to requests.cpu values assigned to containers running on a node. So if two processes are fighting for CPU, the one with higher request gets more. And guess what - the one without any value set will get only what’s left (actually kernel won’t let it starve, but it will be significantly slower).\nFor memory this is more interesting. If container doesn’t have any requests.memory assigned then it will be terminated by linux kernel “killer” feature - Out-of-memory (OOM) killer. It will try to spare those from guaranteed class, probably save some from burstable, but best-effort will be chosen first.\nWhat class should I assign to my pods I can offer the best answer I can - it depends.\nI would go however with the following approach:\nCPU Guaranteed if you have “sensitive” app for cpu spikes OR want to minimize latency it may cause OR don’t want to overcommit CPU resources (Kubernetes scheduler will track and enforce it) Burstable for most, generic workloads with some priorities by setting different request\u0026lt;-\u0026gt;limit gaps according to requirement Best-effort for non-critical workloads, batch jobs and any workload that spans dozens/hundreds nodes since classes are used by local node scheduler ONLY when there’s a higher demand of supply Memory Guaranteed similarly, for “sensitive” apps like databases, anything that runs in StatefulSet since it’s probably critical (it needs storage after all) Burstable for most, generic workloads, I highly recommend setting also limits to minimize OOM kills Best-effort for non-critical workloads, keeping in mind that they will be killed first! How to set a class Place a proper resources section under spec.containers.\nFor OpenShift users you can do it from cli, eg. for jenkins deploymentconfig:\noc set resources dc jenkins --limits=cpu=0.5,memory=1024M --requests=cpu=2,memory=1024M How to check which class my pod belongs to Please check qosClass field of pod’s status. E.g.:\nkubectl get pod MYPOD -o jsonpath=\u0026#39;{.status.qosClass}\u0026#39; Don’t lose hope - LimitRange to the rescue! For those who don’t want to define requests and limits per each pod there’s a LimitRange admission controller which injects default values for you. Here’s a sample configuration object you can apply to your namespace/project:\napiVersion: \u0026#34;v1\u0026#34; kind: \u0026#34;LimitRange\u0026#34; metadata: name: you-shall-have-limits spec: limits: - type: \u0026#34;Container\u0026#34; max: cpu: \u0026#34;2\u0026#34; memory: \u0026#34;1Gi\u0026#34; min: cpu: \u0026#34;100m\u0026#34; memory: \u0026#34;4Mi\u0026#34; default: cpu: \u0026#34;500m\u0026#34; memory: \u0026#34;200Mi\u0026#34; defaultRequest: cpu: \u0026#34;200m\u0026#34; memory: \u0026#34;100Mi\u0026#34; Each container specified in pod defined in a namespace with this LimitRange configuration will get:\nmemory requests=100MiB, limits=200MiB cpu requests=200m, limits=500m Additional parameters define maximum and minimum values that will be enforced for containers with values specified explicitly.\nConclusions Now a quick recap in a few points.\nKubernetes is awesome! Kubernetes scheduler operates on cluster level and linux kernel operates on node/local level Thanks to linux kernel cgroups feature we can easily enforce limits and reservation for cpu and memory of our containers There are three QoS classes: Guaranteed, Burstable, Best-effort Best-effort class is default and is probably the worst choice for most production workloads It’s a good idea to choose class explicitly by setting resources in pod definition or use LimitRange P.S. Puppies have nothing to do with the article (except there are also three of them and are absolutely cute) - it’s just a cheap trick to attract you to visiting my site ;-)\n","tags":["kubernetes","qos","scheduler"],"title":"Treat your pods according to their needs - three QoS classes in Kubernetes"},{"categories":["articles"],"date":"February 22, 2018","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/myths-around-containers-part-3-speed/","section":"articles","summary":"Containers are considerably faster than virtual machines - at least that’s what most people say. But do they actually bring more speed to overall development and deployment process? Let’s find out in the third part of my article series.\nIf you haven’t read first and second part I highly encourage you to do so. But let’s start with the most common myth on speed - the actual time it takes to launch a container.\nMyth: Containers launch faster than virtual machines Basically when you launch container you spawn a new process with a more isolation and without all the overhead you get when you launch traditional virtual machine. And obviously it’s a lot faster - there’s no doubt about it. There’s one caveat however - if an image of a container you’re launching isn’t available on a host it must be downloaded first and it may take some time. That’s why it is crucial for speed to use and create slim images to minimize initial download time. There are other methods to mitigate this issue (e.g pre-download, use common base image, etc.), but in general it is a part of good practice to keep container images small.\nTruth: It’s true - launching containers is like launching a process and it’s very quick provided that your container image is small.\nMyth: Deployment of applications is faster when they are containerized When your applications are available as container images it is possible to leverage features that come with the best container orchestrator - Kubernetes. Deployment process becomes easier, more flexible and faster than ever before. Rolling updates with rollback reduces risk of failure, don’t require downtime and enable thorough testing (including A/B tests, blue/green deployments, multiple environments created on demand and other). All you need to prepare is a proper configuration describing this process and some additional features in your applications like healtchecks or externalized configuration (e.g. credentials, parameters, connections strings).\nTruth: Yes, containers launched on a proper orchestrator engine (i.e. Kubernetes) can be deployed rapidly.\nMyth: Development process is faster If deployment is faster you can assume that so is development. This however depends on your approach to creating containers, because you still need to develop the same code regardless if you want to put it in a container or not. You (or your team responsible for particular service/app) could choose to define each container using Dockerfile with all those “nasty” things written in shell and use Jenkins to build it automatically on each commit. This however can get messy, complex and often not so secure. Better option is to have unified way of injecting app into prebuilt image using source-to-image method promoted and used in OpenShift. You can make the whole process incredibly easy and almost transparent for developers. I personally think it’s the best choice for most cases. So with an app available as container you can launch it easily in a very similar environment using on-demand environment on Kubernetes cluster or you can use a one node, development “cluster” available as light virtual machine ( minikube).\nTruth: If you choose to build containers from scratch it can add more complexity, but with other techniques (like source-to-image) it is less painful and faster.\nMyth: Application in container will run faster Without the overhead from virtualization your app could run faster, but nowadays hypervisors and CPUs can bring this overhead to as little as few percents. So launching container is definitely faster, but when the application is running it becomes less significant whether it runs on container or virtual machine. Actually most deployments of containers are being done on virtual machines, so the same overhead applies there as well - only small number of clusters will benefit of “raw” power available on bare metal. And that lead us to a conclusion - speed of your app still depends on it’s architecture, code quality, resources assigned and available to it, NOT the fact whether it runs on container or not. One thing could bring it to the next level - it’s scaling. For all stateless applications Kubernetes brings scaling (even autoscaling) out of the box, so for workloads dealing with multiple, small transactions it can actually decrease response time.\nTruth: Unfortunately containers won’t speed up your application, however they enable scaling it horizontally which may help it significantly.\nConclusion They launch immediately, because they are just fancier processes similar to the ones you launch everyday on your desktop. You can deploy them faster on many environments using Kubernetes or on any machine using Minikube to make your development easier and rapid as well. They won’t bring significant boost to your app, unless you haven’t used multi-instance behind some loadbalancer deployed before and scaling is something that would distribute your workload decreasing response time.\nYes, containers are definitely great technology that can be treated as a significant milestone. Personally I find it as a major part of Cloud Native approach in developing, deploying and maintaining modern environments. If you choose to embrace containers in your organization you will not only change the way you work, but you’ll be ready for even more radical solutions such as serverless. That’s however a topic for a different article or similar series :-)\nThis was the third and last part of my article series on myths around containers. Hope I shed some light and debunked myths we’ve all been hearing recently - this may help your choose wisely whether invest your time to dive in or stay away and wait for the next “big thing”.\n","tags":["containers","docker","kubernetes","openshift"],"title":"Myths around containers. Part 3: Speed"},{"categories":["articles"],"date":"January 28, 2018","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/myths-around-containers-part-2-portability/","section":"articles","summary":"Is it true that after so many years we finally have real, portable format for all applications? It seems that we’ve come very close to that goal and it’s time to find out more about portability that comes with container revolution.\nIn the first part, I was focusing on containers security. Now let’s take a look at portability.\nPrevious attempts This is another attempt to create an abstraction layer for delivering applications on different platforms - besides unsuccessful format for virtual machines (anyone using OVF format?) there is Java which was supposed to be multi-platform also when it comes to delivering packages. But you can’t run java app without: properly configured OS (dozens Linux distributions, even multiple windows, different architectures), application servers (some apps were written in a way that they just can’t run without), JVM itself and whole bunch of tools around them (logging, cron schedules, connections to external services). In other words - we haven’t got real portability that could satisfy most of applications created nowadays. Until now.\nMyth: There is one common format for apps running in containers It’s one of the biggest success of container revolution - this common format created, respected and implemented by all vendors and projects. It is pretty well documented as standardized ( OCI Image format) and accompanied by runtime standard ( OCI standard). Thanks to Docker Inc. and all the guys involved we don’t have a different format for images itself, but still have many implementations of runtime like rkt and dominant docker engine. The layered concept is the best thing that comes with container revolution - it enables fast deployments, shared responsibility with continuous improvement and it’s just utterly brilliant in its simplicity!\nTruth: It’s true - we have one single format for containers.\nMyth: With one format it’s easy to migrate apps to containers Now that we have this “holy grail”, a common format we should start creating all new applications and migrate existing to containers. I’m a proponent of the former approach, but a skeptic in the latter. Containers are very different from standard/legacy applications in many ways i.e.:\ncontainers are ephemeral - they might appear and be destroyed without any notice configuration is done differently - you cannot do quick fixes on working environment since it’s ephemeral proper building and delivery process is different (harder) - it’s not that easy in distributed, often multi-tenant environments To put it simply - it’s just very different and requires all teams (dev, qa, ops) to learn new, cloud-native way and mindset. On the other hand, modern apps can be migrated with a little effort and leverage all these fancy benefits. I wouldn’t go “all-in” however with all apps in your organization.\nTruth: Migrations are easier for new apps, but still require change many of the processes around development and deployment.\nMyth: Applications for Linux and Windows can share a common platform If you believe that containers were born to join two worlds of Linux and Windows I might have bad news for you - they are not (yet). It is quite hard to have a common format for Windows and Linux containers - even official OCI spec distinguish them. So we have two formats and two worlds, for Linux and Windows. And let me remind you that modern containers were born on Linux and based on its kernel features and Microsoft tries only to catch up after many years believing they could convince community to their Windows-only world. They’re doing an excellent job with that by providing the following:\nbash in Windows 10 SQL server running on Linux .NET core platform for Linux SSH (sic!) server on Windows and many more. It’s not that easy however and we see it by lack of good support in Kubernetes (it’s being developed) and of course, it still requires Windows machines which are from different world when it comes to management, speed and coolness factor :-)\nTruth: Currently, containers run mostly linux-based apps and we still need to wait for better windows support\nMyth: With an app embedded in container you can easily run it anywhere So you’ve put your application in a container image and want to run it to bring value to users. Currently, the following options are the most popular:\nrun it as plain container on your systems without any orchestrators run it on AWS ECS, Docker Swarm, Mesos/Marathon run it on Kubernetes Of course, the last one is probably the best choice, as Kubernetes is the leader (you can find out more why in my article) among container orchestrators. If you chose the other one you probably think of migrating. In theory, that should be easy, but as Kubernetes grows so does a number of features requiring sometimes complex configurations (mostly done with lengthy yaml files). It’s however justified by a long list of abstraction layers for things like networking (SDN plugins, ingress controllers), storage layers (plugins, pv with pvc), own set of standards (CNI for networking, CRI for runtime) which proves that Kubernetes is strongly independent from hardware platforms. What’s more, you will also need to adjust container images definition to meet some specific requirements. For example, on OpenShift you cannot launch container running as user root and there are some few differences when handling deployments (use of own implementation with DeploymentConfig object). Fortunately by using image layers, it’s easier, but still it’s a forced requirement of particular platform. I suspect that there will be more differences on many Kubernetes distributions, especially the ones available on biggest cloud platforms. Otherwise, it would be very easy to migrate your whole system between them in a matter of minutes and that just looks too good to be true.\nTruth: Different container orchestrators need configurations in proper, often quite complex format and even specifically prepared images.\nConclusion In my opinion, common format for a container is a huge win for whole IT world striving to survive the battle between big companies trying to prepare more vendor lock-in traps. Windows containers are still a niche, but if Microsoft will continue to push features and follow conventions born in Linux world then we’ll have a single format for almost all applications. There’s a fly in the ointment - it’s container orchestrators features. Let’s keep our finger crossed to see how future distributions of Kubernetes will differ from each other requiring rebuilding of images.\nThird part is going to be about speed - are containers really that fast? How quick can you deploy, scale and speed up whole development process? Soon I’ll bust some myths around those questions.\n","tags":["containers","docker","kubernetes","openshift"],"title":"Myths around containers. Part 2: Portability"},{"categories":["articles"],"date":"January 7, 2018","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/myths-around-containers-part-1-security/","section":"articles","summary":"We had many revolutions in IT infrastructure world over past 20 years or so. Virtualization promised hardware abstraction, private cloud promised lower costs and flexibility and containers keep adding more to that pile creating a vision of perfect world. It’s a natural part of evolution and progress and that’s okay. I don’t believe however in perfect solutions or empty promises we’ve been told. The same goes for the latest revolution - containerization. Don’t get me wrong - I’m a big fan of putting software in self-contained boxes that you can run anywhere, especially with many abstractions layer brought by Kubernetes, but some might believe it’s something that is just sufficient to make everything perfect from now on.\nLet’s debunk those myths and take a look at promises that have arisen around containers. We’ll start with one of the most important parts - security.\nMyth: you need to focus mostly on securing containers regardless where they run One of my favourite security related questions I ask when I come to a customer is\nDo your servers run in SElinux enforcing mode?\nMost of the time I hear awkward silence followed by negative answer. SElinux is one of the best technology to help your systems secure even when you “forgot” to update them regularly. It’s even better when you adjust it to your software by writing your own. Containers can be more secure the same way virtual machine can with one major exception - they run on a single kernel and thus this single host’a part is crucial, as it affects security of all containers running on it. Another thing are vulnerabilities not yet discovered or published. That’s why it’s so important to keep those “old-school” security mechanisms.\nIt’s even more important after disclosing Spectre and Meltdown vulnerabilities. Regardless how smart you are in securing your containers, you’ll fail miserably when you skip the host part.\nTruth: Container security depends vastly on security of the host it’s running\nMyth: Containers are strongly isolated from host OS and other containers Bare containers are isolated and restricted by default. They are disallowed to call internal kernel functions (syscalls) that may be used to change host system state or do some other harm. The list can extended with seccomp feature to limit them to only ones which are really used and required by your app. This is however similar to writing SElinux policy I mentioned before and boils down to the same conclusion - many people will stick to default settings. Hopefully most will avoid putting container in privileged mode, but I’m sure there will be some brave ones (I’d call them rather lazy and reckless). And if you think that containers are fully isolated then please read this great article from Sysdig. Not all parts of Linux kernel are “container-aware” and many still are shared among all containers running on particular host.\nTruth: Containers bring powerful isolation for those who wants to use it, but they still share some parts of host operating system with host and other containers\nMyth: Using orchestrators makes containers even more secure And what about orchestrators - do they bring even more security? They might. For example OpenShift in its default settings forbids you to launch container running as root - you need to change OpenShift configuration or provide container which runs as non-root user. There are even more settings for storage access, uid mapping and filesystem sharing available - all of those and many more coming from Kubernetes. There’s one thing however where orchestrators are falling behind traditional infrastructure - network traffic isolation. Traditionally we’ve used IP addresses and ports, but in highly dynamic environment it’s no longer that easy. Only this year Kubernetes released mechanism for ingress and egress filtering. Without it control over traffic in constantly changing environment was almost impossible. In mixed environments it’s even worse, as it’s hard to control outgoing addresses container use to access legacy world where access is being controlled via IP based firewalls.\nTruth: Orchestrators can enhance security, some even do it by default, but they still lack of features available in traditional, VM-based environments.\nMyth: Container images cannot be easily tampered with When delivering packages (rpms or debs) you rely on GPG signatures which is enabled by default. You can congratulate yourself if you’ve been using similar approach with containers which is image signing, but many people even haven’t heard of it, let alone used it. The only method used widely to make sure you download untampered images is… https. You trust hub.docker.com by trusting their SSL certificate and built-in verification in Docker client. I’ve seen however many private docker registries using self-signed certs or disabled security for whole IP classes ( –insecure-registry docker option). It’s a serious subject that it’s not that easy to implement and maybe thus not so popular. That’s why OpenShift has ImagePolicy to prevent using images from untrusted sources. I trust guys from Docker that their procedure for official images prevent any tampering and removes vulnerabilities as soon as they are disclosed, but relying only on SSL certificate chain when downloading them is just ridiculous.\nTruth: Container image signing is not enabled by default, it’s not that easy to use and you need to be careful where you’re downloading images from\nConclusion Containers can be much safer in some ways, in some they still falling behind (firewalling, tools), they bring you more security by default (unless you disable it explicitly) and it’s always YOUR job to leverage it.\nAnd do they overpromise when it comes to security? I don’t think so. In many ways you could achieve the same with existing tools. In my opinion people don’t start using containers to increase security - it’s not a major factor when considering investment of precious resources (i.e. people’s time) in adopting them.\nNext time I’m going to have a look at containers portability to see how it’s different from other, well known tools and methods born in pre-container world. Stay tuned!\nUpdate 2018-1-29 - Part 2 published\n","tags":["containers","docker","kubernetes","openshift"],"title":"Myths around containers. Part 1: Security"},{"categories":["articles"],"date":"December 16, 2017","permalink":"https://63db89d1.hugo-coudowski-website.pages.dev/articles/why-kubernetes-has-won/","section":"articles","summary":"We’ve been falling for the containers hype for the past few months and Kubernetes has emerged as a leader among container orchestrator to help build solutions on a bigger scale than your own laptop. Here are 10 reason why it’s won the war and become first choice for container orchestrator.\n1. It’s from Google Yes, it’s been invented by guys from Google and that’s stirs imagination of many who want to create infrastructure similar to one which runs Google search, Gmail and other of their services. What’s more even Google guys claim that it’s a better version of their own, internal orchestrator called Borg.\n2. It’s vendor agnostic Kubernetes hides complexity behind many abstractions layers (i.e. networking, storage, container runtime engine) to enable you to easily switch between technologies used underneath. Use single code to run your apps on any environment regardless if it’s on-premise bare metal, your private cloud or any public cloud provider.\n3. It’s easy for product vendors to integrate with There are many interfaces available for vendors to provide their products as a plugin for Kubernetes and that’s what encourages big companies with big budgets to invest in this technology, support the project and sell their products or services at the same time.\n4. Great support from community Dozens or even hundreds of open source projects around Kubernetes, many blog entries and presentations from people trying to help you understand and use it. And this is something which is very valuable, as with more features also comes more complexity.\n5. Many hosted versions available Major cloud vendors such as Google Cloud Platform, Microsoft Azure and AWS (although still in limited preview) provide hosted versions of Kubernetes on their platforms. Many more versions is going to emerge in the coming months and it would be easier, faster and cheaper to get your own Kubernetes cluster.\n6. It’s free! You can build your whole environment for you containers for free. It’s like you had a VMware vSphere with all these “enterprise” features available for you to use with no cost at all.\n7. Modern and extensible API Whole project is supervised by very smart people (not only from Google, but also from Red Hat, Microsoft and many more) who govern the code and it’s API to be one of the best allowing developers, products vendors and users to leverage it’s power for their needs. As some say you can assess software maturity by looking at it’s API - Kubernetes has one of the best available.\n8. Incredible speed and frequency of new releases In time of writing this article latest version available is 1.9 and it’s the fourth major release in 2017. All of these four versions brought new features presented in thoughtful and well organized manner (alpha, beta and stable api groups). That encourage more features to be included in each new release without unnecessary delay and haste either.\n9. Sophisticated features controlled with simple configuration That’s the real power of Kubernetes - it hides complexity of managing thousands of containers, providing resources for them, orchestrating nodes, gathering metrics in a really simple manner with plain yaml files. Many of complex scenarios can be achieved with just proper assignment of labels (almost every objects is able to have many) or annotations.\n10. Battle tested and already used in production Many companies have already adopted Kubernetes and implemented it in their production environments. It’s not a proof that it’s a perfect solution for everyone, but rather a promise it’s going to be developed, enhanced and bugs be resolved. They have also evaluated other alternatives and still they decided to bet on Kubernetes, probably because of the previous 9 reasons described here.\nConclusion Kubernetes gained such huge momentum that it’s a snowball effect and it’s exciting to see what directions it’s heading. Plenty of features, excellent support and versatility makes it one of the most interesting project that could change the way we deliver and manage applications contributing to container revolution started by Docker. If you plan to use containers in your current or future project then you’ll probably meet with it sooner or later. I expect it’s going to be the former one.\n","tags":["containers","docker","kubernetes"],"title":"10 reasons why Kubernetes has won"}]