-- Leo's gemini proxy
-- Connecting to gemini.tuxmachines.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;lang=en-GB
Tux Machines
Posted by Roy Schestowitz on Mar 02, 2023,
updated Mar 02, 2023
> This article introduces four new projects available in Copr, with installation instructions.
> Copr is a build-system for anyone in the Fedora community. It hosts thousands of projects for various purposes and audiences. Some of them should never be installed by anyone, some are already being transitioned to the official Fedora Linux repositories, and the rest are somewhere in between. Copr gives you the opportunity to install 3rd party software that is not available in Fedora Linux repositories, try nightly versions of your dependencies, use patched builds of your favorite tools to support some non-standard use-cases, and just experiment freely.
> If you don’t know how to enable a repository or if you are concerned about whether it is safe to use Copr, please consult the project documentation.
> This article takes a closer look at interesting projects that recently landed in Copr.
> Do you always forget your passwords, write them on sticky notes and post them all around your monitor? Well, please don’t use Sticky for that. But it is a great note-taking application with support for checklists, text formatting, spell-checking, backups, and so on. It also supports adjusting note visibility and organizing notes into groups.
> I'm a developer. Well, I like to think that I am; I spent twenty-odd years as a software engineer before joining Red Hat ten years ago, and since then, I've been evangelizing the company's tools and products from a developer perspective. I've seen the agile revolution and the rise of containers, and I was there when Kubernetes crawled out of the sea and into our hearts.
> But for the last four or so years, I've found developing containers locally a bit of a challenge. I'm used to being able to just log onto an OpenShift cluster and do my builds, normally through Source-2-Image or just by pointing the system at a Git repo with a Containerfile. But this isn't an option for a lot of developers.
> I also used Docker a lot in the early days, but had a problem when I switched to developing on my Mac instead. To get around that problem, I actually hosted a Fedora virtual machine (VM), amusingly named 'builder', on which I did all my Docker builds. I would prepare all my source, create a Git repo, fire up the VM, ssh into it, clone the repo, build, test. Any problem I had, I would have to drop back to my Mac desktop, fix the code, git add, git commit, rinse and repeat.
> Then along came Podman. Podman is, put simply, Docker with some security enhancements—it solves the old problem of having to run your containers as root, which was always a worry for me when using Docker. The Podman project actually defines Podman as "a daemonless container engine for developing, managing, and running OCI Containers on your Linux System. Containers can either be run as root or in rootless mode."
> It is important to consider multiple factors when deploying production code. Later on, we will deploy, such as securing permission, pulling requests, testing the robustness of the application, and making sure it is tested thoroughly. Deployments will occur in the production cluster after a manual intervention step is added for management approval.
> The advantages of manual intervention are avoiding accidental deployments and achieving governance over the production environment and security. Our goal in this article is to create a manual intervention pipeline. In the middle of the pipeline are the CI and CD.
> We are creating a series of articles about complete CI/CD pipelines on the Red Hat OpenShift Container Platform using Jenkins and Red Hat Ansible Automation Platform. This 3-part series will cover the following topics:
> This article is the third installment of the series. Assuming you have already read the previous articles on continuous integration and continuous deployment, proceed with the demonstration.
> The architecture diagram in Figure 1 illustrates the multiple clusters we will use in this demonstration. Adding manual intervention in CI/CD flow restricts the deployment on production. The purple line represents the production workflow. The workflow triggers when the release manager logs in to the Jenkins dashboard and clicks on approval. Then the Ansible Automation Platform triggers and fetches the playbooks from Git to do the deployment on the production cluster using the token and certificate of that cluster.
> In our previous article, we learned how to create a continuous integration pipeline on Red Hat OpenShift using Jenkins. In this article, we will learn how to perform continuous deployment on OpenShift using the Red Hat Ansible Automation Platform.
> Follow the series:
> This article assumes that you have basic knowledge of Jenkins, OpenShift, and Ansible Automation Platform. You will need administrator privileges for your Openshift cluster to execute this blog.
> The architecture diagram in Figure 1 illustrates all actions that occur after developers push and when Jenkins detects the changes to help with polling or webhooks. When Jenkins triggers the Ansible Automation Platform, continuous integration will occur. The Ansible Automation Platform fetches the playbook and configuration files over Git, which are required for the deployment of game applications. With the help of a template, Ansible Automation Platform deploys the application to the OpenShift cluster.
> In this article series, we will set up a CI pipeline to compile and package a JavaScript game application into a Docker image using Jenkins on Red Hat OpenShift. Once we build the image, it will be pushed to the external Red Hat Quay container registry, Quay.io. When the developer pushes the changes into the Git repository, all these actions trigger.
> This is a series of complete CI/CD pipelines on OpenShift using the Jenkins and Red Hat Ansible Automation Platform. We will cover the following topics:
> This article is based on the assumption that you have basic knowledge of Jenkins, OpenShift, and Ansible Automation Platform. You will also need administrator privileges for your Openshift cluster.
> The developer commits and pushes the changes after initiating the action, as shown in the architecture diagram (Figure 1). Jenkins will detect the changes with the help of polling or webhooks. We build the image in the OpenShift cluster and push it to the Quay.io container registry using buildconfig.
-- Response ended
-- Page fetched on Sat Jun 1 10:14:05 2024