Without proper authentication, our server is wide open to anyone accessing it so we add a username/password combo to act as a gatekeeper to our service:
ARG PASSWORD=test
...
RUN printf "user:$(openssl passwd -1 $PASSWORD) " >> $SRV_PATH/.htpasswd
ARG acts as a build-time substitute for an ENV directive and allows the password to be passed in as a build argument with --build-arg <arg>. If the build is not provided with one, it should default to the argument after the equals sign, which is a very insecure test in this case. We will use this variable a bit lower in the Dockerfile to create the .htpasswd file with a specific password for our user.
The second line uses openssl, which we installed earlier, to take this build arg and create the .htpasswd file with encrypted credentials in a format that NGINX and most other web servers can understand (<username>:<hashed_password>).
If you haven't worked with Bash sub-shells before, $(openssl ...) is run in a separate shell and the output is substituted as a string variable before the rest is evaluated so the >> append operation will only see the encrypted password after username: and nothing related to openssl. As it should be somewhat apparent from these things, if we don't provide any build arguments, the container will have a single username user with a password set to test.
With the web_server piece finished up, we can move to the next piece: the database.