Majority of the Docker Users either forget or don’t find it necessary to change their user privileges and switch to Non Root user. You will find that the Docker Container’s user and group are now changed to the Non−Root user that you had specified in the Dockerfile. To verify that you have been logged in as a non−root user, you can use the id command. This opens the bash of the ubuntu Container. Run the Docker Container associated with the Docker Image. To build the Docker Image using the above Dockerfile, you can use the following Docker Build command. The USER instruction is used to specify which user to be logged in while running the Docker Container associated with the image. The useradd command along with the -u flag adds a user with the specified name and Id using the Docker RUN instruction. In the above Dockerfile, Ubuntu is the base Docker Image pulled from the Docker registry. #Add a user with userid 8877 and name nonroot Docker allows you to add the User using the −u flag along with the useradd command and then using the USER instruction, you can decide which user you want to be logged in as when you start the Docker Container. To verify the group membership, you need to re−login to your Docker.Īnother simpler solution to access a Docker Container using Non Root User, is to specify the instructions in the Dockerfile. If there is already a Docker group in your local machine, the output of the below command would be − groupadd: group 'docker' already existsĪfter you have created the Docker Group, you can now add Non Root Users using the following command. You can create a Docker Group using the following command.
If there is no Docker group, you can always create one. You can try to run Docker Containers as a Non Root User by adding Users to the Docker Group. In this article, we will be discussing two methods to access the Docker Container as a Non Root User. Hence, it becomes very important to perform most of the trivial operations as a non root user wherever possible. Any outsider can misuse this and hack the entire Container along with all the other files and applications running inside the Docker Container. This can prove to be a major concern in terms of security of the application. You might have noticed that when you open an Ubuntu Docker Container Bash, you are logged in as the root user by default. Please check here for more information.When you run an application inside a Docker Container, by default it has access to all the root privileges. Older versions of SBT (which doesn’t support auto plugin) need different configuration. The docker image is now bilt and ready to run. $ sbt build -t image-name /path/to/folder-that-contains-Dockerfileĭon’t want to write a Dockerfile? Use sbt-docker If you don’t want to write a Dockerfile, you can simply use the sbt-docker plugin.ĪddSbtPlugin(“se.marcuslonnberg” % “sbt-docker” % “1.2.0”) Write a Dockerfile (Click here for further Dockerfile instructions) My Dockerfile looks similar to this: This can be done by writing a Dockerfile, or not: The final step is to build a docker container. Now, I will have webapp packaged with all of its dependencies in a fat jar every time I run sbt assembly Step 2: tell sbt-assembly which is the main project (since I don’t want the empty root project to be assembled) Step 1: add the plugin to /project/plugins.sbtĪddSbtPlugin(“com.eed3si9n” % “sbt-assembly” % “0.13.0”) (Similar plugins: sbt-native-package, sbt-onejar, sbt-pack) The one I chose for my project is sbt-assembly. There are many SBT plugins that can be used for this task. To dockerize with SBT my application, first I need a package of the main module with its dependencies. Plus, its documentation is truly instructive.
If you are not familiar with Docker, please check it out here. Now, webapp is run by default with SBT run In my case, webapp is my main module, and I wanted it to be run as default, that’s why I added this configuration into Build.scala: By default, SBT run will try to execute this empty root project and throw on an exception because the project doesn’t contain any executable code. With the above structure, SBT understands that I have 4 sub projects (domains, services, repositories, webapp) and a root one. What I wanted to do was to compile a multi-module project, set one of the modules as the main one, assemble it with all the dependencies needed, then add it to my docker container. While it is obvious that SBT has many advantages compared to Maven (no more freaking long pom.xml files, continuous compilation, continuous testing), its documentation is definitely not my favourite one. A couple of weeks ago, I found myself in a situation where I had to dockerize with SBT a multi-module Scala project. Scala’s popularity has been growing significantly in the past few years as well as Docker.
0 kommentar(er)
