Docker is a technology for creating and running Linux "containers." In some sense, you can think of these as lightweight VMs. A docker container for SpringBoot app will consist of a docker image, which will basically contain a filesystem with all the things needed to run your app (JVM, your source code, etc.), and docker container metadata, which tells the docker daemon how to run the app inside the image (e.g. what environment variables to set, what ports to expose, what commands to run, etc.). The docker daemon will use Linux features such as cgroups and kernel namespaces to run the container in isolation from other processes running on the host machine. Docker is somewhat low-level, in that you need to specify everything that goes into the image, and it runs arbitrary things, namely whatever you put into your image and tell it to run. The docker container that you get is very portable, so you can build, test, and run your docker container locally for development, and then ship that container to a production host that also has a docker daemon running on it, and be quite confident that you're getting the exact same thing.
Cloud Foundry works at a higher layer of abstraction, with applications being a first class concept. Cloud Foundry uses containerization technology similar to docker to build portable images and then run them, but it's an implementation detail and you don't need to specify all the details. In newer versions of Cloud Foundry, docker images will also be supported so you can specify the details if you want, but it also has a "buildpack" workflow, where it will automatically detect a Java application when you push your app and will know to include all the things necessary for the Java runtime when it builds the image.
With Cloud Foundry, since applications and application management are first class concepts, and since it operates at a higher level, you get all sorts of things for free. For instance, you can easily scale your app horizontally (add instances), e.g. 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 crashes, or the process running the application containers itself crashes (the thing that's similar to the docker daemon), or if the host VM that's running the container-running process dies, or the hardware cluster where that VM resides dies, Cloud Foundry will automatically bring your instances back up.
The docker daemon is a single process you can run on any Linux machine. So if you're doing something small and simple, and you need to do most of the setup yourself, it can be easier to get up and running both locally and in development using docker. With docker it's also easier to have access and share the docker image you create, so once you've created an image, you can put it in a docker repository, and then you can run it on any other docker daemon. With Cloud Foundry, the built image is generally an implementation detail and you don't really have access to it, so for instance you couldn't extract that image and run it on another Cloud Foundry installation.
There are various projects out there intended to make Cloud Foundry more accessible and easier to set up, while still giving you many of the benefits of a PaaS. Some of these projects also aim to allow you to combine using docker and the benefits of docker while also getting a lot of the PaaS benefits you get from Cloud Foundry.
See Lattice and Cloud Foundry on BOSH-Lite.
There are also several hosted Cloud Foundry services.
See Pivotal Web Services and IBM BlueMix
There are also a lot of non-CF projects intended to put a platform layer around the core docker technology, in both run-your-own and hosted-service varieties.
See Google's Kubernetes project and Amazon Container Service
Full disclosure: I'm a software engineer working on Cloud Foundry at Pivotal
