Cloud Computing Köln - Seite 3269 von 7127 - Neues zu Cloud Computing, Internet of Things und Technologien

I am sure many of you are as excited as we about cloud native development, and one of the hot topics in the space is Serverless. With that in mind let’s talk about our most recent release of OpenShift Serverless that includes a number of features and functionalities that definitely improve the developer experience in Kubernetes and really enable many interesting application patterns and workloads.
For the uninitiated, OpenShift Serverless is based on the open source project Knative and helps developers deploy and run almost any containerized workload as a serverless workload. Applications can scale up or down (to zero) or react to and consume events without lock-in concerns. The Serverless user experience can be integrated with other OpenShift services, such as OpenShift Pipelines, Monitoring and Metering. Beyond autoscaling and events, it also provides a number of other features, such as:

Immutable Revisions: Deploy new features performing canary, A/B or blue-green testing, with gradual traffic rollout, following best practices and enabling faster interaction.

Ready for hybrid cloud: Truly portable serverless running anywhere OpenShift runs, that is on premise or on any cloud. Leverage data locality or SaaS solutions when needed.

Any programming language or runtime: Use any programming language or the runtime of your choice. From Java, Python, Go and JavaScript to Quarkus, Spring Boot, Rails or Node.js.

One of the most interesting aspects of running serverless containers is that it offers an alternative to application modernization that allows users to reuse investments already made and what is available today. If you have a number of web applications, microservices or RESTful APIs built as containers that you would like to scale up and down based on the number of HTTP requests, that’s a perfect fit. But if you also would like to build new event driven systems that will consume Apache Kafka messages or be triggered by new files being uploaded to Ceph (or S3), that’s possible too. Autoscaling your containers to match the number of requests can improve your response time, offering a better quality of service and increase your cluster density by allowing more applications to run, optimizing resources usage.
New Features in 1.5.0 – Technology Preview
Based on Knative 0.12.1 – Keeping up with the release cadence of the community, we already include Knative 0.12 in Serving, Eventing and kn – the official Knative CLI. As with anything we ship as a product at Red Hat, this means we have validated these components on a variety of different platforms and configurations OpenShift runs.
Use of Kourier – By using Kourier we can maintain the list of requirements to get Serverless installed in OpenShift to a minimal, with low resource consumption, faster cold-starts and avoiding impact on non-serverless workloads running on the same namespace. In combination with fixes we implemented in OpenShift 4.3.5 the time to create an application from a pre-built container improved between 40-50% depending on the container image size.
Before Kourier

After Kourier

Disconnected installs (air gapped) – Given the request of several customers that want to benefit from serverless architectures and its programming model but in controlled environments with restricted or no internet access, we are enabling the OpenShift Serverless operator to be installed in disconnected OpenShift clusters. The kn CLI, used to manage applications in Knative, is also available to download from the OpenShift cluster itself, even in disconnected environments.

The journey so far
We already have OpenShift Serverless being deployed and used on a number of Openshift clusters by a variety of customers during the Technology Preview. These clusters are running on a number of different providers such as on premises with bare metal hardware or virtualized systems, or on the cloud running on AWS or Azure. These environments exposed our team to a number of different configurations that you really only get by running hybrid cloud solutions which enables us to cover a wide net during this validation period and take this feedback back to the community, improving quality and usability.
Install experience and upgrades with the Operator

The Serverless operator deals with all the complexities of installing Knative on Kubernetes, offering a simplified experience. It takes it one step further by enabling an easy path to upgrades and updates, which are also delivered over-the-air and that can be applied automatically, making system administrators rest assured that they can receive CVEs and bug fixes to production systems. For those concerned with automatic updates, they can also opt for manually applying those as well.
Integration with Console
With the integration with OpenShift console, users have the ability to configure traffic distribution using the UI as an alternative to use kn, the CLI. Traffic split lets users perform a number of different techniques to roll out new versions and new features on their applications, the most common ones being A/B testing, canary or dark launches. By letting users visualize this using the topology view they can get quickly an understanding of the architecture and deployment strategies being used and course correct if needed.

The integration with the console provides a good visualization for event sources connected to services. The screenshot below for examples has a service (kiosk) consuming messages from Apache Kafka, while two other applications (frontend) are scaled down to zero.

Deploy your first application and use Quarkus
To deploy your first serverless container using the CLI (kn), download the client and from a terminal execute:
[markito@anakin ~]$ kn service create greeter –image quay.io/rhdevelopers/knative-tutorial-greeter:quarkus

Creating service ‘greeter’ in namespace ‘default':

0.133s The Route is still working to reflect the latest desired specification.

0.224s Configuration “greeter” is waiting for a Revision to become ready.

5.082s …

5.132s Ingress has not yet been reconciled.

5.235s Ready to serve.

Service ‘greeter’ created to latest revision ‘greeter-pjxfx-1′ is available at URL:

http://greeter.default.apps.test.mycluster.org

This will create a Knative Service based on the container image provided. Quarkus, a Kubernetes native Java stack, is a perfect fit for building serverless applications in Java, given its blazing fast startup time and low memory footprint, but Knative can also run any other language or runtime. Creating a Knative Service object will manage multiple Kubernetes objects commonly used to deploy an application, such as Deployments, Routes and Services, providing a simplified experience for anyone getting started with Kubernetes development, with the added benefit of making it autoscale based on the number of requests and all other benefits already mentioned on this post.

You can also follow the excellent Knative Tutorial for more scenarios and samples.

The journey so far has been exciting and we have been contributing to the Knative community since its inception. I would also like to send a big “thank you” to our team across engineering, QE and documentation for keeping up with the fast pace of the serverless space; they have been doing phenomenal work.

Get started today with OpenShift Serverless following the installation instructions!
The post Announcing OpenShift Serverless 1.5.0 Tech Preview – A sneak peak of our GA appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift

17. März 2020

da Agency

First Docker GitHub Action is here!

We are happy to announce that today Docker has released its first Github Action! We’ve been working with GitHub, looking into how developers have been using GitHub Actions with Docker to set up their CI/CD workflows. The standard flows you’ll see if you look around are what you’d expect: building an image, tagging it, logging into Hub, and pushing the image. This is the workflow we’ve aimed to support with our Docker build-push action.

Simplify CI/CD workflows

At Docker traditionally much of our CI/CD workflows has been handled through Jenkins using a variety of products to set up and maintain it. For some things this is the best solution like when we are testing Docker Desktop on a whole variety of different hosts and configurations. For others it’s a bit overkill. Like many, we at Docker have been looking at how we can leverage GitHub Actions to simplify our workflows, including how we use Docker itself.

GitHub Actions already leverages Docker in a lot of its workflows. From having Docker pre-installed and configured on the cloud runners to having first class support for containerized actions allows developers to easily use the same Docker workflows they use locally to configure their repo’s CI/CD. Combined with multi-stage builds and you have a powerful environment to work with.

Docker actions

When we started with Github Actions there were no built-in actions to handle our main build, tag and push flow so we end up with a yaml file, that can’t yet be run locally, full of bash commands. Indeed that’s exactly what you’re given if you choose the “Docker Publish” workflow template from inside GitHub. Though it’s certainly doable it’s not as easy to read and maintain as a script that just uses pre-built actions. This is likely why the community has already published a whole host of actions to do just that. Just go to the GitHub Marketplace and search for Docker actions.

Common things you’ll see beyond just the standard build/tag/push is supporting automatic tagging of images based on the branch you’re building from, logging in to private registries, and setting standard CLI arguments like the Dockerfile path.

Having looked at a number of these we decided to build our own actions off of these ideas and publish them back to the community as official Docker supported GitHub Actions. The first of these, docker/build-push-action, supports much of what has been written above and attempts to build and push images with what we consider to be best practices including:

Tagging based on the git ref (branches, tags, and PRs).Tagging with the git SHA to make it easy to grab the image in later stages of more complex CI/CD flows. For example where you need to run end-to-end tests in a large, self-hosted cluster.Labelling the image with Open Container Initiative labels using data pulled from the GitHub Actions environment.Support for build time arguments and multi-stage targets.Push filter that allows you to configure when just to build the image and when to actually push it depending on any of the data supplied by GitHub Actions and your own scripts. See the examples for one we use ourselves.

A single action approach

But why one big action instead of many small ones? One thing that came up in our discussions with GitHub is how they envisaged that users would create many small actions and chain them together using inputs and outputs but the reality looks to be the opposite. From what we had seen users have been creating big actions and handling the flows internally using inputs for configuration details.

Whilst developing our own actions we found ourselves going the same way, firstly because it’s simply easier to test that way as there currently isn’t any way to run the workflow script locally.

Also this:

– name: build id: build uses: docker/build-action@v1 with: repository: myorg/myrepo tags: v1– name: login uses: docker/login-action@v1 with: registry: myregistry username: ${{ DOCKER_USERNAME }} password: ${{ DOCKER_USERNAME }}– name: push uses: docker/push-action@v1 with: registry: myregistry tags: ${{ outputs.build.tags }}

Is a bit more effort to write than:

– name: build-push uses: docker/build-push-action@v1 with: username: ${{ DOCKER_USERNAME }} password: ${{ DOCKER_USERNAME }} registry: myregistry repository: myorg/myrepo tags: v1

The final reason we went with the single action approach was that the logic of how the separate steps link and when they should be skipped is simple to handle in the backend based purely on a couple of inputs. Are the username and password set? Then do a login. Should we push? Then push with the tags that we built the image with. Is the registry set? Then log in to that registry, tag the images with that registry, and push to it rather than defaulting to Docker Hub.

Feedback is welcomed!

All of this is handled by the image that backs the action. The backend is a simple go program that shells out to the Docker CLI, the code for which can be found here and is built and pushed using the action itself. As always, feedback and contributions are always welcome.

If you want to try out our Docker Github Action you can find it here or if you haven’t used Github actions before you can find a guide to get started by Github here. For more news on what else to expect coming soon from Docker remember to look at our public roadmap
The post First Docker GitHub Action is here! appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/