The newbie cloud architect diary

This article discusses different approaches and solutions around GitOps application delivery for Kubernetes and our path towards the adoption of Flux. The daily mood I requested access to our LucidCharts. Wit this I expect to be able to review any existing chart of our delivery process, and finally be able to create new ones. In the mean time I am looking for available industry solutions and practices around Continous Delivery in Kubernetes. Hereby I found the Manning book GitOps and Kubernetes of a great source of understanding and inspiration. GitOps implementation Basically GitOp supports both  Pull - and  Push -based approach, provided that configuration changes happens either in Git via InfraCode, or on the cluster via new image tags, rather than through the action of a human operator. GitOps can be implemented using existing technology or new emerging tools, thus with some slight differences in the approach, structure and infrastructure support. Poc Our team already ran...

This article dresses a naive picture and history of Continuous Delivery (CD), while introducing GitOps as the best operational model for Kubernetes. The daily mood My manager introduced me the different tracks we are working on. Fortunately I am free to organise my time and directions for ramping-up. For now I have enough backlog with Kubernetes, Helm and Continuous Delivery. Still I hope that he can support my integration within the team, its initiatives and accountability. CD: A retrospective Software delivery has always been a tedious and time-consuming process. In the old times developers were sending an application archive per e-mail to the administrator of an application server, along with database creation statements and application parameters. Developers were potentially using distributed version control (ex. SVN, Git), build and dependency management tools (ex. Maven, Gradle). But they had no idea of how the production environment is configured. Admins were potentially using ...

A Docker registry is an open-source server that is able to store Docker images organised in repositories, and distribute them via an HTTP REST API. The daily mood We had our second team call (we mostly talked about internal/confidential topics). I doubt a bit about my directions, and I feel the need to prevent it to turn into frustration or failure. I wonder if I should involve more support from my team, or apply more structure inside my posts, in oder to ensure productive Goals, Steps, and Results on a daily basis. Though my previous achievements were not too bad after all, so why change and make it worse? Let's rather enjoy what has been done so far and keep going. Following to my  previous blog  on Deployment stacks, I realised that I need a local Docker repository in order to be able to accelerate my deployment activities or switch-off VPN tunnel to our internal network. Docker registry We need a registry hosting a repository. I added an insecure registry entry ...