Docker for data science

Question

I recently started to read articles about Docker.
To me, in data science, Docker is useful because:

1) You have a totally different environment, which protect you against libraries and dependencies problems.

2) If your application modify, for example, the database of your company, you want first to make sure that the code works fine, and won't have bad consequences on the database. Thus, you use Docker to test your code first.

my questions:

• Am I right if I say that only the second reason is about sand boxing? The first reason has nothing to do with sand boxing, right?

• Are there other reasons why Docker is useful in Data science??

• I don't find a lot of interesting research papers about Docker for data science. Do you know some famous ones?

Answer 1

Instead of focusing on the technology term, will provide generalized answer and use the term “containers”.

Containers run only what it supposed to run, assuming anything unknown is untrusted so what only reside in container only for the life of container, so modification of a code in database to test will be same approach in VMs(sandboxing) or containers(docker) and biggest difference is kn resource consumption and time for provisioning VMs vs spinning up containers/pods in couple seconds for application.

More details:

Part1_ From application point of view

Containers are very important when does come to data science world from following points:

• Minimizing conflicting library versions for different development projects(each project has own container/pod to run).
• Consistency across environments and developers against specific design criteria.

• Rapid Prototyping with Edge Node On Demand.

• Avoiding a need to reinstall everything on new hardware after a refresh or failure.

• Portability of your compute environment, develop in your machine and if you need more resources like CPU, RAM or GPU you can port your environment to cloud, powerful clusters, powerful machine, group of containers that can be orchestrated with Kubernetes or Dockerized cluster called Swarm.
• Maximize collaboration clarity across groups. Consistent libraries, result sets, etc.
• Extending on-premises autonomy/agility to cloud scale and reach.
• Project workspaces powered by Docker containers for control over environment configuration. You can install new packages or run command-line scripts directly from the built-in terminal.
• Resources used by containers are very few comparing with VM or Bare metal ... you can have multiple containers running in VM or Bare metal so this will greatly reduce license cost for OS and projects/apps will scale based on resources needed and not full resources of the host( here to note: you will run multiple apps/models in a machine when using containers comparing without containers you’ll use full machine resources for 1 single app/model and this is waste of resources. In a cluster environments you can spin up multiple pods/containers(apps/models across the cluster and with zero cost of the pod comparing with VMs you pay for OS of each host and you run all resources to that task).
• easy to have new image with new packages installed and share with everyone instead to deal with virtual environments into VMs and have conflict of packages and many more(would like to see virtual environments to be moved from traditional approach to containers, that will be a good improvement and will help a lot for Data scientists to bypass the configuration of each project individually with all conflicts and activate/deactivate then search for requirements when putting in production when with containers all you need is a config file, this is my point of view from what I see daily in Data Science world).
• Infrastructure independent platform allows data scientists to run the the analytics applications on the infrastructure best optimized for the applications
• Empower data scientists to build models with the tools and packages best suited for the research without worry of application and environment conflicts.
• Most important Research Reproducibility: The SCALE provided by containers, you scale easily with containers and will be identical across all environments and you don’t care about the host OS, ensuring repeatability of analysis and research with immutable containers and eliminating issues with different environments
• Secure Collaboration: Integrated security in the platform and lifecycle allows for collaboration without risk of tampering and data integrity(more details in Part2&3.

Here comes in play Cloudera with Cloudera Data Science Workbench and Anaconda with Anaconda Enterprise both does use containers so can bring quick results for the business and deploy easy the models from dev to QA and ultimately to production.

Why is important last statement? is to have portability from dev to prod without any changes to environments and without cost DevOps part to operationalize.

Part2_ From security point of view

One notorious security advantage is that the host OS security is separate from the container, meaning that is patched separated, patching host OS wouldn’t impact your containerized application(how many times we have the issue when we do patch the OS and does affect the app and service in that OS(paths, ports, services etc)?

• For example: if you have a malicious library on your app/code than that malware will reside only on that container for the time of container being live, containers does run as endpoint all the time and didn’t saw a case that will spread the malware into network.
• monitoring a container node is robust and you can put add-on or service to monitor behaviors of application or node, and will only replicate new node/container only and only based on config file.

Comparing VMs vs containers: With containers is a different story, you take care of OS separate from containers(containers is separate task when security is in place).

Docker security does provide detailed information of major security points.

Docker standards and compliances provides a full list of security compliances and standards available for containers.

"Docker container with a well crafted seccomp profile (which blocks unexpected system calls) provides roughly equivalent security to a hypervisor."

Folder sharing. With containers, you can share a folder by setting up a shared mount, and since the Docker/kernel enforces file permissions that is used by containers, the guest system can't bypass that restrictions. This is very important for Data Science applications and users because in corporate is used most of the time sensitive/restricted data and multiple layers of security or restrictions are in place, one approach to solve this security problem is using VDI or VMs that with AD group in place to restrict/share data access and does become problematic and costly to maintain and allocate resources.

When does come to debugging applications or OS with all services and logs generated I think containers are winning and evolving now to NLP approach: An experimental natural language processing (NLP) utility is also included, for proofreading security narratives.

Here I will quote Jianing Guo from Google: A properly secured and updated VM provides process level isolation that applies to both regular applications as well as container workloads, and customers can use Linux security modules to further restrict a container’s attack surface. For example, Kubernetes, an open source production-grade container orchestration system, supports native integration with AppArmor, Seccomp and SELinux to impose restrictions on syscalls that are exposed to containers. Kubernetes also provides additional tooling to further support container isolation. PodSecurityPolicy allows customers to impose restriction on what a workload can do or access at the Node level. For particularly sensitive workloads that require VM level isolation, customers can use taint and toleration to help ensure only workloads that trust each other are scheduled on the same VM.

On top of all, kubernetes cluster has following additional security features:

1. Use Transport Layer Security (TLS) for all API traffic
2. API Authentication
3. API Authorization
4. Easy remediation of security flaws and minim impact on application/environment compared with VMs or dedicated Bare metal.

Part3_CIS benchmarks for hardening containers: Docker & Kubernetes.

1. First step making containers more secure is to prepare the host machine that is planed to use for executing containweized workloads. By securing containers host and following infrastructure security best practices would build a solid and secure foundation for executing containerized workloads.

2. Stay up to date on Docker updates, vulnerabilities in the software.

3. Have a specific dedicated directory for Docker related files and allocate just enough space to see for containers to run(default path is /var/lib/docker but change to other mounting point and monitor at OS level using auditd or aide services for any changes or size/unwanted workload run, keep the logs and configure according to the needs.

Note: The best part about step 2 is that with VMs you need to monitor way more locations for your data science project(libraries in different location, multiple versions of packages, locations/path for even python, run cron jobs or systemd to ensure some process does run, log all logs etc but with containers is single point for all this jobs to run and monitor only a path instead of multiple ones).

3. Verify all the time the users into docker group so you prevent unauthorized elevated access into the system(Docker allows the share of directory between the Docker host and a guest container without limiting the access rights of the container) so remove any untrusted users from the docker group and do not creat a mapping of sensitive directories frim the host to container volumes. Here I would say to use a separate user for the installation and specific container tasks "NEVER use root for containers run dedicate a PID only for this task(will have elevated access but will be task based, I use gravitational for the cluster and when installing I NEVER use root).

4. Audit all Docker daemon activities(be aware that does take space the logs in containerized "world" so prepare separate partition with decent space to hold the logs and required configuration(rotation and period to store the logs).

5. Audit all Docker files and docker.service , in etc, var and what else is aplicable.

6. Restrict all inter-container communication, Link specific containers together that are require communication(best will be to create a custom network and only join containers that need to communicate to that custom network). This hardening approach will prevent unintended and unwanted disclosure of information to other containers.

7. All applications in containerized infrastructure should be configured or at least to have th eoption to Encryp All Sensitive Information(this is very importan for Data Scientist because most of the time we do login to platforms to get data, including sensitive data for the company.

8. Have option to have Encrypted All Sensitive Infomration in Transit.

9. Uses only specific approved Ports, Protocols and Services, VMs has more open surface when does come to run an app/project, with containers you specify only what will be used and not wondering for all other ports listening, protocls and services that does run at OS level to protect or monitor, this does minimize the "attack surface".

10. Sensitive information stored on systems is encrypted at rest and does require secondary authentification mechaninsm , not integrated into operating system, in order to access the information.

11. Does allow to be enabled Operating System Anti-Exploitation Features/Deploy Anti-Exploit Technologies: such as Data Execution Prevention(DEP) or Address Space Layout Randomization (ASLR).

12. The best simple security difference between VMs and Containers is: when updating or running a project you don't need elevated access to do it over entire VM or network, you just run as a defined user and if is elevated access then does exist only for the time of the container and not shared across of the host(here does come Data Science libraries install, update, executing projects code etc).

Part4_ More resources(on top of links incorporated in Part1-3) related to containers for Data Science:

1. Data Science on docker
2. Conda, Docker, and Kubernetes: The cloud-native future of data science (sponsored by Anaconda)
3. https://devblogs.nvidia.com/making-data-science-teams-productive-kubernetes-rapids/
4. Why Data Scientists Love Kubernetes
5. A very good book to understand docker usage for Data Science: Docker for Data Science: Building Scalable and Extensible Data Infrastructure Around the Jupyter Notebook Server.

Answer 2

With Docker Swarm Mode you could set up your own secure cluster of low-cost machines.

• So if you are into distributed processig of large datasets, Docker Swarm (and alternatively perhaps the container managemenent tool Kubernetes) can be the basis for deploying Apache Spark (or similar software) on many containers (and/or hosts), for parallel processing.

• If you are into real-time analysis of data streams, you could scale up the cluster relatively easily, according to current demand, without buying lots of expensive network equipment or costly management software from vendors of virtualization technologies.

(I haven't done this personally except for toy examples in the context of MOOCs. However, here is a blogpost from April 2019 about Spark on Docker Swarm, by someone else. - Beware that Swarm Mode was once only available for Docker Enterprise Edition, not the free Community Edition. Now the documentation no longer says so, but I don't know for sure)

Answer 3

Both reasons are about virtual environments and the devops culture which integrates development and operational activities together. I would rather use the terminology "test environment" than sandboxing to describe this function.

Docker is an useful for tool for data science. Other reasons might include that is facilitates collaboration between different parties because everyone is using the same image (your point on dependencies and libraries issues) and it facilitates sharing and managing your application/code/workflow with anyone independent on the OS they use. Basically it is helpful to share code, its management with third parties, and users requests regarding library dependencies etc.

I don't know of interesting research papers but I think the question is a bit similar to asking with there are interesting research papers on Python or R.

Answer 4

Docker is a solution for computer programmers that makes the installation process easier. Its basic premise is that while it functions on this machine, it should work for those as well. From the other user's system, the same requirements and library versions are being used as on yours. Docker makes use of (reusable) tiers. Rather than running apt-get install, pip install, and other tasks locally, users write them into every Dockerfile for every project. The learning slope is small (at most two days of effort), yet the benefits are great.

Docker is a technology that every computer scientist (and now data scientists and analytics) will have in their toolbox. Knowing how straightforward and intuitive Docker has now become, there is no excuse for not incorporating it into your software development life cycle.