In a previous post, we talked about how we can check our Docker images for any known vulnerabilities by means of Anchore Engine. This still required a manual action. Wouldn’t it be great if we could incorporate Anchore Engine into our Jenkins CI build job or pipeline? In this post, we will take a look at how we can accomplish this by means of the Anchore Container Image Scanner Jenkins Plugin.
When using Docker containers in production, we need to ensure that we are following best practices. In this post, we will focus on Ensure images are scanned and rebuilt to include security patches from the CIS Docker Community Benchmark which we discussed previously. The item states that you should scan your images “frequently” for any vulnerabilities and then take the necessary actions to mitigate these vulnerabilities. We will use Anchore Engine in order to accomplish this.
Do you want to experiment with Jenkins CI in a local setup? In this post we will setup a local Jenkins CI server, create a build job for a simple Spring Boot Maven project and push the created Docker image to DockerHub. It will be a setup for local experimenting only, but really handy if you want to try out a Jenkins plugin for example.
You are using Docker for development and testing purposes but did not yet take the step to use it in production? Then read on, because in this blog post we will take a look at how you can ensure that you run your Docker containers in a secure way.
Assume a new developer or test engineer is added to your team. You develop an application with obviously some kind of database and you want them to get up to speed as soon as possible. You could ask them to install the application and database themselves or you could support them with it, but this would cause a lot of effort. What if you handed them over a simple YAML file which would get them up to speed in a few minutes? In this post we will explore some of the capabilities of Docker Compose in order to accomplish this.
On Thursday the 31st of May I went to the J-Spring conference at Utrecht, the Netherlands. J-Spring is the largest one day Java conference in the Netherlands in the spring organised by the NLJUG (Dutch Java User Group). The title of the event might be a bit misleading as you may think that it is only about Pivotal’s Spring, but it is more than that. In this post I want to share my experiences that day.
In part 1 of this post, we learned how to create a Spring Boot application, create a Docker image for it and push it to a Docker registry. At the end, we installed Minikube in an Ubuntu VM. In this second part, we will get familiar with some Kubernetes terminology, deploy the application to our Minikube cluster and update the application. The sources used for the application can be found at GitHub. The Docker registry which we use can be found here (or you can use your own Docker registry).
In this post we will take a look how we can build a Spring Boot application, create the Docker image, deploy it to a Docker registry and deploy it to a Kubernetes cluster. This will give us the opportunity to get acquainted with the basics from building an application up to deploying it to Kubernetes. Sources can be found at GitHub.
In part 2 of this post, we will refactor the application written in part 1 in order to use a database. We will take a short look at the choices we have when selecting a database in combination with Spring WebFlux, use an embedded version of the database, refactor the sources and find solutions for the problems we encounter. The code can be found at GitHub in branch mongodb.
In this post we will continue exploring the capabilities of Spring WebFlux by means of creating a basic CRUD application. We will not be using a database in this post because I did not want to be distracted with database stuff at this moment 😉 Adding a database will be handled in part 2. Furthermore, we will implement a few CRUD operations and see how we can unit test a Flux. Source code can be found at GitHub.