If you're not familiar with Docker and you wonder where to start from, I'd recommend the following Pluralsight course by Nigel Poulton: Getting Started with Docker
Another hint is using VS Code with Docker extension. So what you can do is:
- Install Visual Studio Code on your machine (will work nicely on Linux as well).
- Go to the "Extensions" tab and install the Docker extension.
- Open up your project as a folder in VS Code.
- Invoke the command prompt (Ctrl+Shift+P) and type "Docker" to observe the available commands.
One video to get started with Docker in VS Code is this one: VS Code Docker Extension - Overview
And here's a more CAD-oriented topic about Docker in FreeCAD: Docker Image for OpenCascade Development
When and why would someone come across Docker and things like that? For me, it was simply the case of several failed deliveries I made to my customers on Linux. Picture this. You have your application up and running in your environment, so to deliver things you just make up a tarball out of the working directory. You would expect this "portable" tarball to contain all the necessary deps, especially, if you haven't forgotten to copy all the libs in one place and adjust LD_LIBRARY_PATH in the runner bash script. That resembles a very simple way of packaging apps on Windows: just put all the runtime libs in one folder and fire up your entry-point executable from there. But on Linux, it’s not quite working that way.
So you deliver this whole tarball via FTP or something and keep your fingers crossed just in case anything goes wrong. And it does. You get annoying feedback that your application simply crashed on its very launch because of missing this and missing that. This is then joy begins. You have to discover what's missing or maybe the customer has to clean up some libs from the provided package to get things alive. Such cleanup might be necessary in the cases when the target system comes up with the different versions of the libs you "bundled in." Or maybe there's something you completely forgot for the runtime because you installed some critical package a year ago on an absolutely irrelevant occasion. In moments like this, you know that you need a Docker even if you have no idea of what Docker really is or even if you never heard about Docker before. Because what you really need is to ship exactly the same libraries you have in your development environment to the production environment. You need to send out a package and not bother your customers with the necessity to wire things in manually.
What we're actually looking for is a clean sandbox to deploy our application from the very beginning, not assuming any dependencies pre-exist in the target system. This is one thing. Another thing is the build instruction in the cases you deliver in sources. You can spend many hours carefully explaining all the steps one has to take to build up your software from scratch on a clean (too nice to be true) system. Alternatively, you could just give out the corresponding Dockerfile that contains the entire building recipe in a very human-readable way. And if this sandbox (container) works for you, it will almost surely work out just as well for your client. And that starts to be a reasonable thing.
So what we get with Docker is a kind of light super-fast virtual machine for our app. All these containers share the same OS kernel, which is the main idea of Docker virtualization. There are two concepts to bear in mind when working with Docker: an image and a container.
- An image is something like a class in object-oriented programming. Or something like a VM template if you will. So it has to be materialized with an instance (a container).
- A container is a sort of object materialized from an image.
Build OpenCascade in Docker container
Here's the video explaining how to build OpenCascade in a Docker image: Lesson 6: OpenCascade in Docker
Make sure to subscribe to our Youtube channel to have more fun with OpenCascade in the future.