Docker is a technology for creating and running Linux containers. In a way, you can think of it as a lightweight VM. The docker container for the SpringBoot application will consist of a docker image, which will basically contain the file system with all the things needed to run your application (JVM, your source code, etc.) and the docker container metadata that tells the daemons dockers to run the application inside the image (for example, which environment variables to set, which ports to set, which commands to run, etc.). The docker daemon will use Linux features, such as groups and kernel namespaces, to launch the container separately from other processes running on the host machine. Docker is somewhat low-level, because you need to specify everything that is included in the image, and it launches arbitrary things, namely everything that you put into your image and tell it to start. The docker container that you receive is very portable, so you can create, test and run your docker container locally for development, and then send this container to the production node, which also runs the docker daemon, and be sure that you get something same thing.
Cloud Foundry works at a higher level of abstraction, with applications being a first-class concept. Cloud Foundry uses docker-like containerization technology to create portable images and then launches them, but that’s implementation detail, and you don’t need to specify all the details. The new versions of Cloud Foundry also support docker images, so you can specify the details if you want, but it also has a "buildpack" workflow, where it automatically detects a Java application when your application is clicked and knows to include all the things necessary for the runtime Java when it creates an image.
With Cloud Foundry, since applications and application management are first-class concepts, and since it works at a higher level, you get all kinds of things for free. For example, you can easily scale the application horizontally (add instances), for example. cf scale my_app -i 5 or vertically, cf scale my_app -m 2G (to set the allocated memory for each instance). You get streaming application logs: cf logs my_app . Cloud Foundry gives you a lot of fault tolerance for free, so if one of your application instances fails, or the process that starts the application container itself (which is similar to the docker daemon), or if the host virtual machine is working with the container, the testing process or hardware cluster stops Where this VM is located, Cloud Foundry will automatically return your instances.
The docker daemon is the only process you can run on any Linux machine. Therefore, if you are doing something small and simple, and you need to do most of the configuration yourself, it is easier to start and run both locally and in development using dockers. With docker, it is also easier to access and share the docker image they created, so once you have created the image, you can put it in the docker repository, and then you can run it on any other docker demonstrator. With Cloud Foundry, the inline image is usually part of the implementation, and in fact you do not have access to it, so for example, you could not extract this image and run it on another Cloud Foundry installation.
There are various projects designed to make Cloud Foundry more accessible and easier to configure, while providing you with many of the benefits of PaaS. Some of these projects are also designed to combine the use of dockers with the benefits of dockers, as well as the many benefits of PaaS from Cloud Foundry.
Watch Lattice and Cloud Foundry on BOSH-Lite .
There are also several Cloud Foundry services.
See Basic Web Services and IBM BlueMix
There are also many CF-free projects designed to place the platform layer around the dock technology within both its own and hosting services.
See Google Coubernetes Project and Amazon Container Service
Full disclosure: I'm a software engineer working at Cloud Foundry at Pivotal