Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2021, 14 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lessons Learned Deploying Traditional Web Applications on Top of Kubernetes - Marcos Bjoerkelund

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Lessons Learned Deploying Traditional Web Applications on Top of Kubernetes - Marcos Bjoerkelund, VMware

Traditional web applications are still very popular among developers, and it is unlikely that this will change over the course of the next few years. Deploying these applications on top of Kubernetes is a challenge as they are not usually designed to be run in such environments. In this session, you will learn from Bitnami’s experience how best to make your traditional web application run on Kubernetes. Attend this session to see a step by step guide on how you can create a container image for a traditional application, build its configuration scripts, and run it on Kubernetes with a Helm template. We will also talk about some of the challenges you may face, such as supporting for scaling or automatic application updates, and ways to solve them.

A

Hi welcome to all of you, I'm marcus birklund, I'm based in spain, and I work at vmware, which I joined via the acquisition of vietnami in 2019.

A

Today, I'm going to talk about some of the lessons we have learned at binami, while deploying traditional web applications on top of kubernetes.

A

This talk is structured into five parts. First, we will have a brief introduction.

A

Next, we will talk about some of the different steps you will follow if you want to deploy a traditional web application on top of kubernetes afterwards, we'll give some tips and good practices and discuss over some particular challenges. You may find and finish the talk with an example.

A

At the end, I will be here to answer any questions you may have.

A

First, I wanted to talk a bit. My about my company bitnami, which is not part of vmware, is a catalog for web applications, runtimes frameworks and more that can be deployed in multiple environments, platforms and formats, such as container images or hand charts.

A

We have more than 10 years of experience deploying web applications on these environments. In fact, our catalog contains almost 100 traditional web applications, and more of 20 of them can be deployed in kubernetes via hand, charts.

A

Let's talk a bit about traditional web applications, there are so many of them incredible popular ones, less popular ones, etc. This is just a small version of the ones that we support at minami in one of those platforms, and you will easily recognize more than one logo.

A

They are not designed to work in cloud native environments the date to before that will the same thing. So how can we differentiate traditional and cloud native applications? I have compiled a few basic requirements that we will expect any kubernetes native apps to meet, so they can be deployed without any headache.

A

Traditional applications, however, don't usually meet one or more of these requiring work routes and hacks. In some cases, it might even be impossible to solve these problems. Let's talk about them.

A

First, the applications process may be stateful share resources between them. Next, there may be no separation between application code data and configurations not allowing to specify deployment inputs without relying on configuration files stored in the local disk.

A

The application may not be ready to be stopped at any point of time or require some time to boot. Up this usually happens a lot in java applications such as jenkins.

A

The application may not support horizontal scaling due to design limitations. Usually this happens when it relies on the local disk for storing data.

A

Finally, tabs should specify an exact list of dependencies, that is, it has been testing working with and and ideally with, the standard way to install them, for example, with the package manager such as npm, to avoid any issues when running the application.

A

We have also created a guitar responsibility. For this talk to complement with examples and more detailed explanations. It is on github.com, slash, vietnamex, slash, deploy web apps and kubernetes.

A

You don't need to copy the link right now, as we will be referencing it throughout different parts of this talk.

A

Now, let's briefly revisit how you would proceed, if, if you wanted to deploy a traditional web application on top of kubernetes here, you can see a list of basic steps. You will need to follow. If you want to deploy it, you will need to first build a container image, build a hem chart and then deploy and operate on kubernetes.

A

For this talk, we will be mostly focusing on the building process for container images and charts. I'll tell you the base step for running an application of kubernetes.

A

Let's start with the building of container images.

A

When we talk about container images, we reference the oci compliant images. This can be run on docker, pod man or kubernetes. For instance. A particular thing about container images is that you can run code at twitch stages at build time and at run time.

A

First, you can work out when you build the image via the docker file. It includes a series of steps to define your image, which, in this case means you can build and run the application. It is based on layers each command in the docker file executed. On top of the previous layer, you can specify inputs, but they will only be used when building the image.

A

In the example on the right, you can see how an example docker file would look like and how you would deploy it. Its format is really simple: the runtime is specified by an entry point script. Here you will run scripts to install a running application.

A

You can specify external inputs via environment variables or mounted files.

A

Let's talk a bit about docker file design, it should contain all the steps to install the application dependencies copy application files and prepare it, so it can run as well as making it secure.

A

Now it is heavily recommended that you also optimize the image size and also ensure that installation can be performed with as much stability as possible. You would also specify runtime configuration defaults, such as the default entry point default, values for inputs, etc.

A

Now about entry point design, ideally, it should contain steps to validate inputs persist, the application data start the web application itself, with the focus and taking the levels amount of time to deploy then other things that would be nice to have like logic, to configure the application free external inputs waiting for external services to be available, so the application doesn't throw any error or other post installation features, for instance, to automate the installation in the database.

A

Next, let's talk about hand, charts helm is known, as the package manager for kubernetes is the most popular way to deploy web applications. On top of it, a home chart contains a collection of kubernetes resource templates that can be extended via inputs during deployments.

A

It supports complex architectures via soup, charts, meaning that the chart can include another chart.

A

The right you can see a basic file structure of a hand chart and below. You will see the steps to the deploy it into kubernetes.

A

About helm, chart designs, there are so many things that you might want to support some things you will mostly always include for your traditional web applications. For instance, deployment for application containers ingress with tls word. Persistent volume claims to store your application data or secrets to storage credentials.

A

Other things you should consider supporting will be supporting the database in a subchart or using an external database for it metrics grant jobs, customer resources, etc.

A

Finally, let's talk a bit about build and release pipelines.

A

Why would we want a release pipeline? Well, it will allow you to perform tedious manual steps in an automated way. It should contain the steps to build both the container image and hemp charts, plus the automated testing releasing or publishing of both of them.

A

One of my work colleagues presented last year in kubecon talking about the internal bitnami, build and release pipeline. If you're interested in the topic feel free to check it out, it's on youtube.

A

Finally, I also wanted to mention that there are a few alternatives if you want to implement your own cei, ci or cd pipeline. All of the examples is listed here have a free tier if I'm not wrong, and there are also open source alternatives like jenkins, which we use at bitnami.

A

Now, let's talk about some tips and good practices when building container images and hemp charts.

A

First, you should consider running containers as non-root users. This is because it allows to protect from previous privilege, escalations and access to non-writable files. For instance, if a malicious user gained access to your application's file system, it will greatly limit the stuff they can do to make. It behave in an undersizable way.

A

There are different alternatives: you can follow running a known system user or an existing user with an arbitrary user or an arbitrary user id and an unknown username.

A

The problem with the first two is that they are either insecure or they are not supported in all platforms and they do not follow the best security practices and recommendations.

A

For these reasons, we heavily recommend con running containers with an arbitrary user id and no unknown username. It might not be compatible with all apps, but you can work around this with nss wrapper. Another side effect of having no username is that the shell prompt may look a bit ugly.

A

This doesn't mean it is broken in this case, any writable file must belong to the root group, because any username that has no name belongs to the root group by default.

A

Now, let's continue talking about permissions, it is important to set this at build time, as non-root images may not only lack the privilege to change them at runtime, but also because it may be slow at build time. We have the all the time of the world to do so.

A

So what files should we make writable? Well any file that the application requires to modify at runtime? If there is a clear separation between application code and data, then only data files will need to be writable.

A

You will need to identify the list of files and folders that are writable when you create the image.

A

It might be the application requires access to the entire source directory. In case you will need to make all files writable. Finally, I recommend to check the docker security cheat sheet from the oasp foundation.

A

It contains some good security topics that you should review when creating your content images, the most relevant one will be with respect to read-only file systems.

A

If you want to support that, you need to identify the list of application files and folders that need to be writable like mentioned above and create an appropriate volume for those then populate the volumes at runtime, if applicable,.

A

Next, there is other topics like using linux security models such as apb armor, second or se. Linux.

A

Another important factor when creating your container image is the image size, so we know that container images follow a layered format. This has its good things, but one of the things that can go wrong comes when we modify a file in different layers. It gets counted twice. Even changing the file mode or ownership will have this effect, and why would you want to fix this?

A

It is important because it will affect bandwidth usage in deployment time. If the image is not stored locally, it will need to be downloaded, so we can be talking about several several gigabytes of data transfer. Here there are some strategies you can follow to easily achieve an optimal image size first by using multi-stage images to build your application.

A

This is especially useful for applications that need further steps to be built with a specific build dependencies.

A

The next options consist of strategically implementing your docker file grouping, any actions that may modify a file more than once, removing temporary files etc and all in a specific order. This may lead to docker files that are hard to read.

A

The final thing you should consider if, if the previous two are not possible for your case, is to use darker's squash feature, it is some sort of nuclear option, as this has some important limitations, but it's up to you to consider if there is no other way.

A

I also wanted to talk about the useful tool called dive. This tool allows to inspect images for big files, so you can check where to start optimizing, the image size. You can see this example of a wordpress image, which is more than one and a half gigabyte in size.

A

When we were when we optimized it, we were able to take it down to less than the half of the size. That's a lot of space that the user saves, but also in deployment time as it does not need to be downloaded.

A

Now, let's talk about some good practices, creating container images, we have collected a guide on some of the best practices you should follow. When writing a doc file find a link to it. In this page, the main recommendation consists of running only one process per container.

A

We will discuss different ways to work around this problem later at build time. You would ideally run heavy and time consuming tasks to boost traffic application and avoid those at one time.

A

You should also be aware of any possible possible reproducibility issues when building the image, for instance, network connectivity issues.

A

As for maintenance, it is highly recommended to rebuild the image periodically.

A

This could allow you to minimize the response time in case of a security incident affecting a dependency of your application, or even by detecting a potential build errors before a rebuild becomes urgent.

A

A mistake we made has been numbing in the past, consisted of using an external tool to initialize the application it has so did this had some issues with respect to visibility and debug, but the main issue was that in some environments it has such a huge memory impact that it will cause issues when initializing in kubernetes due to setting resource limits.

A

Other things you should consider at this stage will be to support for multi-arc such as emd64 plus arm or choosing your own distor, among other things,.

A

As for charts design,.

A

As for charts design, I've linked here a guide on some of the best practices, creating hand, charts ready for production, find also a link to the public. Hemp chart template we're using at bitnami. When we add any new solution, I will mainly recommend that you configure it to deploy non-root containers by default and allow operators to extend this to. They will.

A

Find some examples here, for instance, by loading to specify custom container commands or disable pros.

A

Integrate with login and monitoring platforms such as elk or prometheus, add diagnostics features to make it easier to debug problems in deployment. In case anything happens.

A

Now, let's discuss some of the challenges you may find and how to solve them. If you want to, if you want your application to work properly in kubernetes, you need to ensure that persistence is properly set up. If not, you may lose data after the container gets recreated.

A

As a general rule, you should only persist data files and folders that need to be writable by the application at runtime.

A

The application separates data and code. In this case it it could make our task easier, be aware that there are many applications that don't do it.

A

This approach is faster when you do the first initialization, because it needs to copy less files. Just imagine if you had to copy an entire multi-application via the network to a different volume.

A

A last point in favor in this is that it makes it easier to upgrade application by just swapping the container images.

A

If the application doesn't have any code and data separation, then you will need to persist the entire application source code. This can be slower than the previous approach.

A

Think of the example we mentioned, the other downside of this approach is that it forces the operator to deal with any sort of maintenance and upgrade tasks which approach you choose is up to you. You should consider the pros and cons of each one of those.

A

Now, let's talk about support for automatic updates, we understand automatic updates as the process where the operator does not need to manually run any upgrade command or wizard to a great application.

A

Note that before you make any upgrade, it is essential that you backup your database and scale down to onenote if the application is running through multiple nodes.

A

If the application separates code and data, like I mentioned above, it makes it easier for the operator to upgrade by just swapping the container image version.

A

Another way this can be implemented is if the container is, if the application itself supports some sort of automatic accurate process like wordpress, where the operator doesn't even need to worry about clicking on the upgrade button, as the application does itself. Does it automatically?

A

The problem with this method is that this requires the application itself to have to have right privileges to modify the application source files. This is not ideal. With respect to permissions, it also makes it more complicated to roll back in case any error occurs.

A

If the application does not provide any of those features, that is code and data separation or an automated ui update tool, then the operator will be forced to perform a manual upgrade process on their own.

A

Another issue you may find is that your application requires multiple services to work, but when the general rule is not running more than one process in a container, then what do you do?

A

Well, there are two main problems we haven't identified related to this first, when the application has a set of external dependencies or services that need to share data with the main component or process like, for instance, via the use of workers.

A

In this case, you should check if it allows to do that with an external service like redis. If not, you can set up a synchronized or cached file system such as nfs, with a downside of a notable write performance.

A

The next problem comes with respect to frontend and backend servers requiring access to the same application files. In this case, you should check if there is any way to host external resources via a cdn.

A

If not, you can also rely on shared or catch fire systems like we mentioned, above with a notable impact on performance.

A

In this case, you can also use a catch server like varnish for catching front-end resources to help in the performance drop.

A

Other cases you may find could be periodic jobs in this case, kubernetes offers a current job resource definition that you can use to work around these issues or you may want to execute some pre-installation steps. Apart from what is in the container logic, in this case, you can use an init container.

A

The last challenge we will talk about is horizontal scaling. Ideally, your application will fully rely on external services and host no local data whatsoever, making it easier to scale horizontally. For example, you will have a web server to host application data, a different hosting a different server for hosting temporary files, such as cache sessions, etc, usually done via redis, memcached and other types of servers.

A

Then you would have a cdn for hosting the application assets, user, uploads, most others and an external load balancer as the main entry point from users to access the application itself.

A

In reality, traditional applications require hosting local data like we have mentioned before, and the solution to that may be using a synchronized file system, even with that the application may not support it due to extra limitations.

A

In this case, all you can do is optimize it. For instance, you can use a cache server like varnish to reach the load from the application services optimize. The application configuration to your needs or even scale vertically, if needed,.

A

Now that we have seen all the different steps involving in deploying application in kubernetes, including how to build a good container image and a good hand chart, let's see a real world example, we are going to describe how to deploy a very popular application in this case wordpress and kubernetes, following following some of the best tips and practices mentioned in this talk.

A

First, let's see how a component time gram would look like in this case the user will connect to the http port of an nginx container, which would then communicate any requests to php fpm via a proxy and using the mariadb container as a database.

A

The only container we will focus on for this talk would be the one that executes the wordpress application. In this case, the php fbm container.

A

This is an example of a real docker file that could be used to build and run the wordpress application. Don't be scared, we will. We will be describing it step by step.

A

You can see here that we are using a multi-stage, build in this case to build the application in a separate container and save space in the overall image size. We are using the same image as the runtime to save space as well.

A

We are installing build dependencies in this case for the c url command extracting the application and adding any customizations on top of it.

A

Next, we are defining the new image, the final image, using a minimal container image with a minimal size.

A

We are adapting it to our needs installing runtime dependencies. Finally, installing wordpress from the multi-stage build applying any runtime configurations, persisting the wp content as the data folder for wordpress and running everything as a non-root user.

A

This container is using a entry point, script that we are describing here in the same way we're describing it by step by step like like before.

A

First, we are setting bash strict mode and load functions, which is a good practice. Next, we are determining if the application is being initialized. If it is, then we will persist the application data files. This is only on the first one. It may take a bit more time than the usual, but in successive successive runs it shouldn't do much.

A

It should be almost instantaneous another step that we do in the first initialization is validating inputs, running custom, commands, etc.

A

Finally, we start the application and that's it that's that's. Basically, a container image.

A

Now for the chart now that we have a continued image, we want to deploy it on kubernetes.

A

The chart includes a lots of files, so we will not be describing into detail because we lack the time in right now, but we have collected two examples. One of those is the vietnamese wordpress chart, which used the losses in apache plus mod php approach.

A

Some basic features is that it uses mariadb subchart as the database, but also allows to specify an external database. It also supports caching via wordpress, plugin, plasma and cache.

A

We have also created for this tag, specifically an nginx plus php fpm example. Basing on the vietnamese wordpress chart, refer to the link to the github repository for this talk and check it out.

A

So thanks so much for attending. I really hope you enjoyed this session. You learned a lot and I encourage you to ask any questions and share any feedback. I would love to hear from you see you.