Run an Nginx Image as Non-Root Within a Multi-Step Docker Build Process

Joel Lord
InstructorJoel Lord
Share this video with your friends

Social Share Links

Send Tweet
Published 3 years ago
Updated 3 years ago

Running our server as a Non-Root user is very important for testing things such as quality assurance. Many things can get missed when using a privileged account such as your root user account. Here we need to set up and change the Nginx configuration to run as a Non-Root user.

This container uses two steps. The first step uses a container to build the production version of your VueJs application. This container won’t be deployed on a server, its purpose is to create the necessary files for the second step. It's fine to leave this container running as root.

In the next step of the build, the Nginx server is the one that will need to run as a non-root user because it is actually run on servers you want to deploy to. To do so, you will first need to change the Nginx configuration to run the build using the Nginx user with files modified for that user to access them.

Instructor: [0:00] It is now time to tackle the frontend container. This container uses two steps. The first step uses a container to build a production version of your Vue.js application. This container won't be deployed on a server. Its purpose is to create the necessary files for the second step, and then we don't use it anymore.

[0:18] The NGINX server is the one that we will need to run as a non-root user. To do so, you will first need to change the NGINX configuration. Start by creating a file in the front folder called "nginx.conf." Now, open up your editor to modify this file.

[0:38] First, you will need the basic required configuration parameters for an NGINX configuration file. Without going into the details of all the different steps, this is what is the strict minimum required to start your NGINX server. Next, you will need to change the server settings to run on port 8080 instead of the default port 80, which is restricted to the root user, can do so a listen option in your server object to 8080.

[1:05] You can also change the default path that NGINX uses to serve files from in the location, object-type route for the root folder, and we can do /code, which is a directory that we will create and give the necessary permission to your users.

[1:19] Now that you have a new NGINX configuration file that will let the server run as a regular user, it's time for you to edit your Docker file one last time. This modified container will run as, user nginx. In this case, the NGINX base images provides us with a non-root user.

[1:40] In many cases, you will see user 1000 being used. This is an arbitrary number. You could use just about anything, or even create a user with the user added command. Using user 1000 is a standard way to do this in Docker when a non-root user is not provided.

[1:57] In the second step of your build right after you specify the from statement, you can copy your new NGINX configuration file to overwrite the default one. Then, similar to what you did to your backend, you can create a /code folder using the mkdir command and change the ownership with the chown command.

[2:24] You should also change the file permissions to 755. Next, there's a series of files and folders that NGINX needs to access to in order to run. You can change the ownership of all of these folders in a single-run statement using ampersands to change those commands. NGINX also requires an nginx.pid file. This file does not exist yet, so you need to create it and assign the ownership to the NGINX user.

[3:02] Finally, you need to change the group to those files and folders, as well as change the permissions, so that NGINX can read and write to these folders. You can do this with a last run command. Change the group, var/cache/nginx, var/run, var/log/nginx, var/run/nginx.pid. Change the file permissions with, chmod to 755, to those same folders.

[3:39] As you are changing all permissions in the file system, you can move the lines from your original Docker file that copied the Start NGINX file right in this section. Now that all permissions have been adjusted, you can tell Docker to switch over to the NGINX user using the user statement.

[4:00] You can then remove that WORKDIR command and copy the files into the /code folder. Also make sure to add the --chown flag to the copy statement, so that the files will be writable by the NGINX user.

[4:16] Finally, you need to tell Docker that this new image uses a different port. To do so, you will use the EXPOSE statement for the port 8080. This is done just before you start the server with the ENTRYPOINT command.

[4:32] Before you rebuild this container, you will also need to change the start-nginx.sh script. The files are no longer stored in this directory and are now stored in /code/js/app-start.js.

[4:51] You are now ready to rebuild those two containers and start everything again. From the front folder, run a Docker build with the name k8s_course_front and . for the current working directory. Go to the backend folder and run that Docker build again with the name k8s_course_back. Use . for the current working directory. You are now ready to start all of your containers again. You can use the same commands as you did previously.

[5:39] When starting your new frontend container, don't forget that you now need to map port 8080 instead of the port 80, as you did previously. Once again, you can point your browser to localhost:8080. Everything should be running again, but this time, everything is running as regular users, making it more secure.

[6:00] Furthermore, this will make it easier for you to deploy on various servers, as some of them would have blocked your containers running as root. Now that you have everything containerized, you will need to share these containers with the rest of the world. That is what we'll do in the next lesson.

egghead
egghead
~ 7 minutes ago

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today