DevNation Tech Talks are hosted by the Red Hat technologists who create our products. These sessions include real solutions plus code and sample projects to help you get started. In this talk, you’ll learn about Argo CD and Tekton from Siamak Sadeghianfar and Burr Sutter.
Continue reading Argo CD and Tekton: Match made in Kubernetes heaven
The need to deliver applications faster is near-universal, even in organizations that traditionally are perceived as risk-averse. As the foundations of DevOps, continuous integration (CI) and continuous delivery (CD) are essential to application delivery in most organizations. Together, CI/CD tools and processes automate building and testing applications on every code or configuration change, then trigger a sequence of workflows that deliver the application to production.
Continue reading The present and future of CI/CD with GitOps on Red Hat OpenShift
As Kubernetes and Red Hat OpenShift platform adoption grow and organizations move a larger portion of their infrastructure to these platforms, organizations are increasingly faced with the challenge of managing hybrid multicluster environments across the public cloud and on-premises infrastructure. While this approach brings flexibility and scalability to managing applications, the ability to ensure configuration consistency across these clusters, and the ability to roll out applications to multiple clusters in a consistent manner becomes a necessity. Enter the Argo CD GitOps Kubernetes Operator.
Continue reading OpenShift joins the Argo CD community (KubeCon Europe 2020)
Tekton is an open source project that provides standard Kubernetes-style resources and building blocks for creating CI/CD pipelines that can run on any Kubernetes. Tekton does this by introducing a number of custom resource definitions (CRD) such as Pipeline, Task, and ClusterTask to provide a language and structure for defining delivery pipelines as shown in Figure 1. Tekton also provides a set of controllers that are responsible for running pipelines in pods on demand whenever a user creates an aforementioned resource.
Figure 1: A Tekton pipeline contains a sequence of tasks.
The use of Tekton has grown rapidly over the last year. One of the frequently requested features is the ability to share artifacts between tasks in order to cache dependencies for build tools such as Maven and NPM. Although it was possible previously to use volumes in tasks, the release of Tekton 0.10 adds support for workspaces, which makes it easier for tasks within a pipeline to share artifacts using a persistent volume.
In this article, we look at how workspaces can be used to cache Maven dependencies in Java builds in order to remove the need to download dependencies for each build.
Continue reading “Speed up Maven builds in Tekton Pipelines”
Red Hat OpenShift 4.1 offers a developer preview of OpenShift Pipelines, which enable the creation of cloud-native, Kubernetes-style continuous integration and continuous delivery (CI/CD) pipelines based on the Tekton project. In a recent article on the Red Hat OpenShift blog, I provided an introduction to Tekton and pipeline concepts and described the benefits and features of OpenShift Pipelines.
Continue reading “An introduction to cloud-native CI/CD with Red Hat OpenShift Pipelines”
[In case you aren’t following the OpenShift blog, I’m cross posting my article here because I think it will be of interest to the Red Hat Developer commnity.]
The Open Service Broker API standard aims to standardize how services (cloud, third-party, on-premise, legacy, etc) are delivered to applications running on cloud platforms like OpenShift. This allows applications to consume services the exact same way no matter on which cloud platform they are deployed. The service broker pluggable architecture enables admins to add third-party brokers to the platform in order to make third-party and cloud services available to the application developers directly from the OpenShift service catalog. As an example AWS Service Broker created jointly by Amazon and Red Hat, Azure Service Broker created by Microsoft and Helm Service Broker created by Google to allow consumption of AWS services, Azure services and Helm charts on Kubernetes and OpenShift. Furthermore, admins can create their own brokers in order to make custom services like provisioning an Oracle database on their internal Oracle RAC available to the developers through the service catalog.
Continue reading “Using Ansible Galaxy Roles in Ansible Playbook Bundles”
[Cross posted from the OpenShift blog]
About a year ago Red Hat announced its participation as a launch partner of the Istio project, a service mesh technology that creates an application focused network that transparently protects the applications from abnormalities in environments. The main goals of Istio are enhancing overall application security and availability through many different capabilities such as intelligent routing, circuit breaking, mutual TLS, rating, and limiting among others. Ultimately Istio is about helping organizations develop and deploy resilient, secure applications and services using advanced design and deployment patterns that are baked into the platform.
As part of our investments in making the technology easily consumable to Kubernetes and OpenShift users, Red Hat has created a ton of content:
Continue reading “Getting Started with Istio and Jaeger on Your Laptop”
Cloud-native application development is the new paradigm for building applications and although is it often mistaken for microservices, it is much more than that and encompasses not only the application architecture but also the process through which applications are built, deployed, and managed.
New apps are often seen as the focus of cloud-native applications; however, we believe existing and new applications are alike and can incorporate cloud-native practices if they have the four defining characteristics of cloud-native applications:
The Getting Started with Cloud-Native Apps lab at Red Hat Summit 2018, which takes place in San Francisco on May 8–10, has a packed agenda that focuses on walking participants through the principles of building and operating cloud-native applications.
Continue reading “Red Hat Summit Spotlight: Getting Started with Cloud-Native Apps Lab”
Jenkinsfiles have only become a part of Jenkins since version 2 but they have quickly become the de-facto standard for building continuous delivery pipelines with Jenkins. Jenkinsfile allows defining pipelines as code using a groovy DSL syntax and checking it into source version control which allows you to track, review, audit and manage the lifecycle of changes to the continuous delivery pipelines the same way that you manage the source code of your application.
Although the groovy DSL syntax which is called the “scripted syntax” is the more well-known and established syntax for building Jenkins pipelines and was the default when Jenkins 2 was released. Support for a newer declarative syntax is also added since Jenkins 2.5 in order to offer a simplified way for controlling all aspects of the pipeline. Although the scripted and declarative syntax provides two ways to define your pipeline, they both translate to the same execution blocks in Jenkins and achieve the same result.
Continue reading “Building Declarative Pipelines with OpenShift DSL Plugin”
A recent Gartner survey suggests that roughly 50% of the respondents planned to implement continuous delivery and DevOps by year-end 2017 in order to deliver services faster, more often and more reliably. State of DevOps Report by Puppet Labs suggests that high-performing organizations that focus on automation and DevOps are able to reduce their lead-time for delivering a change by a factor of 440 and deliver services 46 times more often. These results have helped to make DevOps adoption a mainstream enterprise IT phenomena. As a result, today we see DevOps adoption in virtually all industries and company sizes, and the perception of DevOps as a unicorn capability has long vanished.
Continue reading “How Kubernetes Helps to Enable DevOps”
