June 2023 Summaries

Matthew Casperson's article, published on June 28, 2023, delves into the complexities of implementing role-based access control (RBAC) in Kubernetes as clusters grow in complexity. It explains the distinction between roles, cluster roles, role bindings, and cluster role bindings, highlighting how roles and role bindings are namespace-specific, whereas cluster roles and cluster role bindings apply across the entire cluster. Through various scenarios, such as linking a service account to roles and cluster roles using bindings, the article demonstrates how permissions can be strategically managed within and across namespaces. The text emphasizes that while role bindings can connect cluster roles to service accounts, they limit access to the namespace where the binding is created, whereas cluster role bindings provide access across all resources without namespace restrictions. The article concludes by pointing out the utility of cluster roles in defining common permissions without duplicating roles across multiple namespaces, enhancing the efficiency of Kubernetes deployments.

Kubernetes configuration has been simplified with a new feature that allows direct sourcing of YAML manifests from Git, eliminating the previous need for an interim packaging step before deployment to Octopus. This change retains the benefits of the package approach, such as release immutability, while introducing advanced scenarios like configuration templating. Users can reference and modify YAML files across multiple projects using Octopus variables, facilitating the management of numerous similar services. The feature supports deploying multiple applications in one step, offers flexibility with glob patterns for file referencing, and maintains structured variable replacement for those needing valid YAML for local testing. Octopus allows users to hide Kubernetes complexity by creating step templates that limit the properties software teams need to adjust, streamlining the deployment process. The feature is expected to be available to Octopus Cloud customers by early July and to Octopus Server customers later in 2023, with user feedback encouraged for further refinement.

Many organizations in the software industry are shifting away from cloud computing and microservices due to concerns over cost and performance, leading to trends in repatriation and consolidation. Repatriation involves moving applications back to on-premises infrastructure, which can offer more predictable costs and improved performance, while consolidation sees companies merging multiple microservices into fewer macroservices or even monolithic applications to reduce complexity and enhance efficiency. This shift is not a regression but a recalibration, as organizations seek the balance between cloud-native and cloud-nomad architectures, which prioritize portability and flexibility across various hosting environments. Cloud-nomad architecture, an evolution of cloud-native principles, emphasizes the ability to move applications seamlessly between cloud providers and on-premises setups, avoiding vendor lock-in and embracing infrastructure automation. This approach mirrors ancient nomadic practices, focusing on the portability and adaptability of software infrastructure, ensuring that applications can be easily relocated without significant reconfiguration.

Octopus 2023.2 introduces a feature called Step Retries, designed to enhance deployment efficiency by allowing automatic retries for steps that fail due to transient errors. This feature can be activated on individual steps via the Conditions section, where if an action fails, it will retry from the failed point instead of restarting the entire step, with a 15-second delay between each of the three retry attempts. While Step Retries cannot be applied to certain steps such as Send an Email, Manual Intervention, Health Check, and Deploy a Release, it aims to reduce manual interventions during deployments. Users must configure retries for each step manually, as there is currently no option to default retries to 'on' for all steps, and customization of the number of retries is not yet available. If retries fail, the guided failure mode will engage if enabled, and user feedback is encouraged to further enhance this feature.

Ubuntu's Docker image is the most downloaded on Docker Hub, with over a billion downloads, serving as a reliable base for creating custom Docker images. The text explains how to optimize these base images by using Ubuntu's Long Term Support (LTS) releases for stability and security, disabling suggested and recommended dependencies to reduce image size, and installing additional packages non-interactively to avoid errors. It highlights best practices such as setting the DEBIAN_FRONTEND environment variable to noninteractive during installations, cleaning up package lists to maintain a lean image, and creating non-root users for enhanced security. By adopting these tweaks, developers can create smaller, more secure Docker images for their applications, while also being encouraged to explore other popular container images and deployment tools like Octopus Workflow Builder for further enhancing their DevOps practices.

Docker is an effective platform for packaging and running web applications, especially when paired with cloud-based Platform as a Service (PaaS) options, and NGINX provides an official Docker image that enables DevOps teams to host web applications. This text illustrates how to use the NGINX Docker image to create and run custom web applications, starting with a basic command to launch an NGINX container and extending to the creation of custom Docker images embedding static HTML files. It delves into advanced configuration by explaining how to add custom configuration files for additional functionalities, such as a health check endpoint, and discusses the benefits of smaller image sizes using Alpine-based NGINX images compared to the default Debian-based ones. The guide concludes with a nod to other popular Docker images and resources for further exploration, highlighting the flexibility and power of using NGINX within Docker to host web applications while also mentioning tools like the Octopus Workflow Builder for deploying applications to AWS platforms.

Octopus Deploy has updated its deployment targets to allow Polling Tentacles to use the standard HTTPS port 443 instead of the previously used unassigned port 10943, which often caused security concerns and required lengthy firewall exception approvals. This update, available from Polling Tentacle version 6.3.417 or later, involves configuring a second URL with a reverse proxy to reroute Polling Tentacle traffic, allowing firewall rules to only require port 443 open for outgoing traffic. This change is particularly beneficial for Octopus Cloud customers, but it can also be applied to self-hosted Octopus Deploy instances with certain configurations. The new setup is backward compatible with existing systems using port 10943, enabling a mix of configurations during transitions.

Octopus Deploy emphasizes the importance of pragmatic deployments through its "10 pillars" framework, which is designed to enhance the deployment process by making it repeatable, verifiable, seamless, recoverable, visible, measurable, auditable, standardized, maintainable, and coordinated. These pillars are not rigid rules but guidelines to identify process gaps, shape product features, and drive discussions on effective software deployment. Key concepts include the integration of continuous integration and deployment (CI/CD) practices, the use of deployment strategies like blue/green and canary deployments to minimize disruptions, and the importance of metrics and audits for tracking and improving deployment outcomes. Octopus aims to support deployments that are adaptable to individual needs while maintaining a focus on reliability and efficiency.

Bicep is a user-friendly language designed to simplify the deployment of Azure resources using ARM templates, and the new "Deploy a Bicep template" step aims to enhance this process further. To use this step, an Azure account is required along with the Azure CLI's Bicep module, which can be installed using the command `az bicep install`. The deployment process allows for storing Bicep templates either in a source code editor or in packages, with the latter enabling the use of multiple templates and local file references. Users must provide parameters as key-value pairs and select a deployment mode, either incremental or complete, which determines how Resource Manager handles existing resources. If a specified resource group does not exist, it will be created during deployment, and its location must be specified. The process includes periodic polling and reporting of the deployment state, with output parameters available for accessing deployment details. For support, users are encouraged to engage with the Community Slack channel.

Octopus plans to phase out support for Mono in future releases, prompting users who deploy to SSH targets via Mono to transition to .NET Core. Mono, a CLI virtual machine enabling .NET code execution on non-Windows platforms, has been integral to Octopus since 2015 for Linux deployments. However, with the rise of .NET Core as the dominant cross-platform framework, the cost of maintaining Mono, including development, testing, and support expenses, now outweighs its benefits. Octopus will begin warning users of the upcoming changes in version 2023.2, with functionality being disabled by default starting from version 2023.4. Users are encouraged to switch to the self-contained Calamari (.NET Core) option by adjusting their deployment target configurations, which typically requires minimal changes. While most users will experience minor impacts, specific platforms such as RHEL6 and FreeBSD may require additional attention or upgrades. The overall goal is to modernize the deployment process by eliminating dependencies on older technologies like Mono.