Uploaded byAltoros
Persistent Storage with Containers
The adoption of containers has brought with it a lot of promises: fast creation times, efficient hardware usage, portability across various OS’s, and more. The potential of containerization to make the management of applications easier and better, is what has made containers one of the hottest topics in tech over the last few years. With sky-high and climbing adoption rates, it seems like everyone is trying to containerize. Talks on how to make the best containers abound, but what about trying to containerize more traditional (monolithic) applications that have significant data requirements? Where does persistent data fit in to the hot new container landscape? In this talk, we’ll discuss what containers mean for data. We’ll explore what options you have for dealing with various data requirements alongside containerized infrastructure. And you’ll learn how the promises of containerization can benefit your infrastructure from a broader perspective.
Persistent Storage with Containers
- 1. Copyright © 2017,Oracle and/or its affiliates. All rights reserved. | Persistent Storage with Containers Kaslin Fields – Solutions Architect at Oracle Cloud Infrastructure Cloud-Native and Kubernetes Meetup – 7/19/2018 Twitter: @kaslinfields Confidential – Oracle Restricted
- 2. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. Confidential – Oracle Restricted
- 3. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | The Promise of Containers • Fast • Efficient • Portable • Scalable • Immutable Confidential – Oracle Restricted
- 4. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Immutability Adjective: “unable to be changed” - Mirriam-Webster https://www.merriam-webster.com/dictionary/immutable
- 5. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Immutability and Containers • Containers should never change on the fly • No Patching – Just recreate it! • Dependencies included – No more “It works on my machine” • Application-focused – Only the app and its dependencies! • Made to Die – Cattle, not pets Confidential – Oracle Restricted
- 6. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Immutable Containers and Persistent Storage • If my containers can never change while they’re running, then where’s all my data supposed to go?? • Separate the App from the Data – Containers for Apps – Volumes for Data Confidential – Oracle Restricted
- 7. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Use Case - Wordpress • Surprisingly difficult to containerize IMMUTABLY • A traditional app – Database – Clearly needs to PERSIST – Numerous (expected) local filesystem locations which store data which needs to PERSIST Confidential – Oracle Restricted
- 8. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Persistent Storage with Containers - Tools • Docker – Volumes • Kubernetes – Volumes – Persistent Volumes – Persistent Volume Claims Confidential – Oracle Restricted
- 9. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Docker • Docker is a container implementation format • Docker Volumes – Came out in 1.8.0 (July of 2015) – Local – Plugins • Docker Swarm is a container orchestrator – Docker Volumes work natively with Swarm – Though generally a Docker Volume will get provisioned on every node in a Swarm* Confidential – Oracle Restricted
- 10. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Docker Volume Plugin on OCI Confidential – Oracle Restricted $ docker volume create --driver oci --name persStor Install Docker OCI API $ docker run -it --rm -v persStor:/mnt busybox sh Mount Busybox
- 11. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Kubernetes • Kubernetes is a container orchestrator • Volumes – Tied to pod lifetime – Fun Fact: Kubernetes released 1.0 in July 2015 • Kubernetes Persistent Volumes (and Persistent Volume Claims) – Now in Beta! (April 2018) – Alpha in 1.8 (September 2017) Confidential – Oracle Restricted
- 12. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | OCI FlexVolume Driver - Setup Confidential – Oracle Restricted https://github.com/oracle/oci-flexvolume-driver AVAILABILITY DOMAIN 3AVAILABILITY DOMAIN 2AVAILABILITY DOMAIN 1 REGION Kubernetes Workers REGION AVAILABILITY DOMAIN 3AVAILABILITY DOMAIN 2AVAILABILITY DOMAIN 1
- 13. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Confidential – Oracle Restricted OCI FlexVolume Driver – Setup (Pod Definition) https://github.com/oracle/oci-flexvolume-driver
- 14. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Confidential – Oracle Restricted OCI FlexVolume Driver https://github.com/oracle/oci-flexvolume-driver REGION AVAILABILITY DOMAIN 3AVAILABILITY DOMAIN 2AVAILABILITY DOMAIN 1 $ kubectl apply –f pod.yml
- 15. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Confidential – Oracle Restricted REGION AVAILABILITY DOMAIN 3AVAILABILITY DOMAIN 2AVAILABILITY DOMAIN 1 OCI Volume Provisioner https://github.com/oracle/oci-volume-provisioner/ Flexvolume Driver & Volume Provisioner
- 16. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Confidential – Oracle Restricted OCI Volume Provisioner https://github.com/oracle/oci-volume-provisioner/
- 17. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Confidential – Oracle Restricted OCI Volume Provisioner https://github.com/oracle/oci-volume-provisioner/
- 18. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Confidential – Oracle Restricted OCI Volume Provisioner https://github.com/oracle/oci-volume-provisioner/ REGION AVAILABILITY DOMAIN 3AVAILABILITY DOMAIN 2AVAILABILITY DOMAIN 1 $ kubectl apply –f pod.yml
- 19. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Persistent Storage Tools in Review • Docker – Works with Docker Containers or Swarm • Can also be used with Docker containers running on Kubernetes – though this doesn’t take advantage of Kubernetes’ orchestration features – Use local storage or a plugin • Kubernetes – Be mindful of the physical state of WHERE your app is running – Persistent Volume Claims & Persistent Volumes Confidential – Oracle Restricted
- 20. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Let’s Talk About Databases • Can you run them in containers? – CERTAINLY! • Oracle DB - https://github.com/oracle/docker-images/tree/master/OracleDatabase • MySQL - https://hub.docker.com/_/mysql/ • Oracle RAC - https://github.com/oracle/docker-images/tree/master/OracleDatabase/RAC • Should you run them in containers? – Ehhh, it depends… Confidential – Oracle Restricted
- 21. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Kaslin’s Guidelines for Databases in Containers • Great for testing environments • Great for applications which require a tightly coupled DB, like WordPress – Kubernetes Pod-style • Not so great if you have 0 tolerance for your DB APPLICATION going down – Though stateful sets can help with this SOME • Should be good if you expect the DB’s STORAGE to always be up! – Granted you’ve planned out your storage requirements appropriately. Confidential – Oracle Restricted
- 22. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | A Simple Rule for Containerizing Databases Confidential – Oracle Restricted 1. If your DATA needs to be persistent, you’re probably good. 2. If your access point to that data, the DATABASE APPLICATION, needs to be as close to 100% up-time as possible - there are probably better options.
- 23. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Let’s Review • Immutability means your container, once built, never changes. – It gets remade instead! • Application = Container • Data = Volume • Both Docker and Kubernetes have tooling to help manage data volumes – With plugins available from various vendors Confidential – Oracle Restricted
- 24. Copyright © 2018,Oracle and/or its affiliates. All rights reserved. | Thanks! Q&A Confidential – Oracle Restricted
Editor's Notes
- #2 The adoption of containers has brought with it a lot of promises: fast creation times, efficient hardware usage, portability across various OS’s, and more. The potential of containerization to make the management of applications easier and better, is what has made containers one of the hottest topics in tech over the last few years. With sky-high and climbing adoption rates, it seems like everyone is trying to containerize. Talks on how to make the best containers abound, but what about trying to containerize more traditional (monolithic) applications that have significant data requirements? Where does persistent data fit in to the hot new container landscape? In this talk, we’ll discuss what containers mean for data. We’ll explore what options you have for dealing with various data requirements alongside containerized infrastructure. And you’ll learn how the promises of containerization can benefit your infrastructure from a broader perspective. Kaslin Fields is a Solutions Architect focusing on containers (particularly Kubernetes) at Oracle Cloud Infrastructure. As a Solutions Architect, she spends most of her time creating blog posts, demos, and other materials to help guide Oracle’s customers into the world of containerization. Oracle Cloud Infrastructure’s recently released Kubernetes service, Oracle Kubernetes Engine (OKE), is a great way for Oracle customers to get started using Kubernetes in the cloud. Before joining Oracle, she was a Hybrid Cloud Architect at NetApp where she developed a Dockerized hybrid-cloud performance testing infrastructure.
- #4 Why do so many people care about containers so much? The traits that drive the incredible rate of adoption we’re seeing about can be descried pretty simply: *list* Containers spin up fast. Faster than VMs. This speed makes microservices possible in a way that wasn’t available previously. Without the overhead of a guest operating system, containers can utilize hardware more efficiently than VMs can. Containers share the kernel of the machine they’re running on. In Linux, this means that Docker doesn’t care what flavor of Linux you’re running. So long as your kernel is compatible, you can run the same container on Ubuntu as on Oracle Linux. The speed, efficiency, and portability of containers combine to make them compelling as a scalable solution. Getting too many hits on your website and need more servers to handle the requests? Spin them up as containers and you could have that taken care of in milliseconds. And all this is made possible because containers are expected to be IMMUTABLE. The word “Immutable” gets thrown around a lot in the container world, but I can’t say I ever really hear it anywhere else. So I decided to take a note out of Dan Finneran’s DockerCon presentation (which I’ll give you the info to find later) and define it:
- #5 The definition I found is a bit shorter than the one he found. Immutability means “unable to be changed”. Short, sweet, and to the point. “Containers are Immutable.” “Containers are unable to be changed.” That’s the goal. Let’s elaborate a bit more on what that means and why it’s so important – and it is very important when it comes to persistent storage, as you’ll soon see. *next slide*
- #6 Immutability means that containers should never change on the fly. For years, I have been speaking about containers at conferences, meetups, and to friends and colleagues. One of the biggest misconceptions I’ve heard over the years is that the way containers make everything so much easier and better, is that you can spin up a container, make your changes, save it, and then send it out to all the places it needs to go. This is not quite right. You should never change a running container. Immutability says that once created, a container never changes. If you need to make a change, you make a whole new container. Say you’re running a .NET app in a Windows container, and that app needs an update or security patch. You shouldn’t try to go into the container and apply the patch. You should make a new version of that container which includes the patch. This change to the way we do things can be quite beneficial. Rather than an operations person having to worry about all these different versions of things existing in concert on a given environment, you have clear versions of each container, which provides isolation for the app as well as good version tracking. Now that you’ve got those patches in, hopefully your app has all the dependencies it needs to run. A great thing about containers as an application delivery method is that your app takes its dependencies with it everywhere it goes. This is often marketed as a solution to “It works on my machine” because with containers, you should never have a problem of an app working differently on one person’s machine than another’s because of a missing or outdated dependency. Everything’s all bundled up to make sure the application runs right. Put it all together and you see that immutable containers are really very application-focused. As the packaging mechanism for the app and its dependencies, the container allows developers to worry about the app they’re creating rather than the environment that app is going to run in. And it allows operations people running those apps a similar degree of freedom (so long as container isolation is sufficient.). But probably the biggest change to traditional thinking that immutable containers brings, is this. Containers, are MADE TO DIE. Which means the APPS that are running on them must be made to fail as well! This is an integral component of microservices, where the applications are intended to spin up, do their thing, and then die, leaving your resources free to be used for other tasks. But even non-microservice containerized applications need to live by this “Made to Die” principle. Because what about when that patch comes out? That’s another case where your container needs to die and be made anew. And then we have failure cases. This comes up more when you talk about container orchestration. Kubernetes, the top container orchestrator, is so popular in part because it can spin your containers back up if any of them die unexpectedly. So whether an expected death like microservices or upgrades, or an unexpected failure, you should always expect that unlike some monolithic applications many companies have been running for decades on the same hardware, your containerized application is going to die someday. And die, it should. This is a fundamental change to the way we traditionally think about application deployment. Now by this point, some of you have probably noticed why I’m talking about all this in a presentation about Persistent Storage. -
- #7 Now by this point, some of you have probably noticed why I’m talking about all this in a presentation about Persistent Storage. - If your containers can never change while they’re running – and writing new data inside the running container would be a change – then where’s all your data supposed to go?!
- #8 Before we get into the tools you can use for persistent storage with containers, let’s focus in a bit with a use case. Wordpress. A very common application. Also one that is perhaps surprisingly ill-suited to life in containers. -Bet you haven’t heard that much, have you? You hear all these ways that containers are wonderful, it’s rare to hear a specific case where containers themselves make things difficult. And don’t be mistaken, containers can add sufficient value to Wordpress deployments to be worth using anyway. Here’s why I say Wordpress is difficult: Wordpress was designed in what might be referred to as a “traditional” architecture. It expects a lot of data to be on-hand for it to use at any time. It does have a database – which is great for containers. We’ll talk a bit more about containerizing databases the right way later, but let it suffice for now to say that creating a database to use with a wordpress container is no problem. As someone who has been working in a containerized mindset for some time and who is new to Wordpress. I thought containerizing that DB was gonna be enough for me. I thought “Oh this is great, they did the work of separating out that persistent data for me!” They didn’t. If you deploy containerized wordpress with a containerized DB, and wordpress goes down, yes, your DB data will be fine so long as you did that right. But there is other data wordpress expects to exist in a specific folder local to the wordpress deployment (so on the container in this case). So if you didn’t do anything to protect that data and your container goes down… POOF. It’s gone. And you end up with this janky wordpress installation that has some of your old data, but not all of it. It might be worth noting that at DockerCon 2018 I participated in a hallway track lead by a Docker Captain, that consisted just of the Docker Captain and various attendees discussing how difficult it is to run Wordpress in containers the right way. So, with that in mind, let’s talk about how we can solve this problem!
- #12 “Managing storage is a distinct problem from managing compute.” - https://kubernetes.io/docs/concepts/storage/persistent-volumes/
- #14 Here is an example of a pod definition from the tutorial on the FlexVolume Driver github page. You can see here how the volume mount (where the volume will be mounted in the container) is defined. You can also see how the volume itself is defined. This tells Kubernetes what type of storage you want to use and how to use it. In this case it’s saying that we want to use the oci flexVolume driver – which tells Kubernetes how to connect to OCI storage. And it’s also giving a filesystem type. Like I hopefully mentioned with the Docker volumes, Docker expects volumes to have filesystem. There is a different Docker feature for using straight block devices. So if you’re using block storage, you need a filesystem.
- #18 Notice – no node selector this time. Since the storage will be created in the same AD as the Pod. No need to know the volume name (ocid) – because there isn’t one yet.
- #19 Doesn’t matter where the pod goes, the storage will be created with it. But when the pod dies, the storage will remain.