instruction: Create a Dockerfile for Nginx, Node.js with production best practices
output: ```dockerfile
  from the location of the site.conf secret to /etc/nginx.conf.d/, where
  Nginx looks for extra configuration files. This step happens before Nginx
  actually starts, so you don't need to rebuild your image if you change the
  Nginx configuration.
  NoteNormally you would create a Dockerfile which copies the site.conf
  into place, build the image, and run a container using your custom image.
  This example does not require a custom image. It puts the site.conf
  into place and runs the container all in one step.Secrets are located within the /run/secrets/ directory in the container
  by default, which may require extra steps in the container to make the
  secret available in a different path. The example below creates a symbolic
  link to the true location of the site.conf file so that Nginx can read it:
  
  $ docker service create \
   --name nginx \
   --secret site.key \
   --secret site.crt \
   --secret site.conf \
   --publish published=3000,target=443 \
   nginx:latest \
   sh -c "ln -s /run/secrets/site.conf /etc/nginx/conf.d/site.conf && exec nginx -g 'daemon off;'"
  Instead of creating symlinks, secrets allow you to specify a custom location
  using the target option. The example below illustrates how the site.conf
  secret is made available at /etc/nginx/conf.d/site.conf inside the container
  without the use of symbolic links:
  
  $ docker service create \
   --name nginx \
   --secret site.key \
   --secret site.crt \
   --secret source=site.conf,target=/etc/nginx/conf.d/site.conf \
   --publish published=3000,target=443 \
   nginx:latest \
   sh -c "exec nginx -g 'daemon off;'"
  The site.key and site.crt secrets use the short-hand syntax, without a
  custom target location set. The short syntax mounts the secrets in `/run/secrets/
  with the same name as the secret. Within the running containers, the following
  three files now exist:/run/secrets/site.key/run/secrets/site.crt/etc/nginx/conf.d/site.confVerify that the Nginx service is running.
  
  $ docker service ls
  
  ID NAME MODE REPLICAS IMAGE
  zeskcec62q24 nginx replicated 1/1 nginx:latest
  
  $ docker service ps nginx
  
  NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
  nginx.1.9ls3yo9ugcls nginx:latest moby Running Running 3 minutes ago
  Verify that the service is operational: you can reach the Nginx
  server, and that the correct TLS certificate is being used.
  
  $ curl --cacert root-ca.crt https://localhost:3000
  
  <!DOCTYPE html>
  <html>
  <head>
  <title>Welcome to nginx!</title>
  <style>
   body {
   width: 35em;
   margin: 0 auto;
   font-family: Tahoma, Verdana, Arial, sans-serif;
   }
  </style>
  </head>
  <body>
  <h1>Welcome to nginx!</h1>
  <p>If you see this page, the nginx web server is successfully installed and
  working. Further configuration is required.</p>
  
  <p>For online documentation and support. refer to
  <a href="https://nginx.org">nginx.org</a>.<br/>
  Commercial support is available at
  <a href="https://www.nginx.com">nginx.com</a>.</p>
  
  <p><em>Thank you for using nginx.</em></p>
  </body>
  </html>
  
  $ openssl s_client -connect localhost:3000 -CAfile root-ca.crt
  
  CONNECTED(00000003)
  depth=1 /C=US/ST=CA/L=San Francisco/O=Docker/CN=Swarm Secret Example CA
  verify return:1
  depth=0 /C=US/ST=CA/L=San Francisco/O=Docker/CN=localhost
  verify return:1
  ---
  Certificate chain
   0 s:/C=US/ST=CA/L=San Francisco/O=Docker/CN=localhost
   i:/C=US/ST=CA/L=San Francisco/O=Docker/CN=Swarm Secret Example CA
  ---
  Server certificate
  -----BEGIN CERTIFICATE-----
  â¦
  -----END CERTIFICATE-----
  subject=/C=US/ST=CA/L=San Francisco/O=Docker/CN=localhost
  issuer=/C=US/ST=CA/L=San Francisco/O=Docker/CN=Swarm Secret Example CA
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 1663 bytes and written 712 bytes
  ---
  New, TLSv1/SSLv3, Cipher is AES256-SHA
  Server public key is 4096 bit
  Secure Renegotiation IS supported
  Compression: NONE
  Expansion: NONE
  SSL-Session:
   Protocol : TLSv1
   Cipher : AES256-SHA
   Session-ID: A1A8BF35549C5715648A12FD7B7E3D861539316B03440187D9DA6C2E48822853
   Session-ID-ctx:
   Master-Key: F39D1B12274BA16D3A906F390A61438221E381952E9E1E05D3DD784F0135FB81353DA38C6D5C021CB926E844DFC49FC4
   Key-Arg : None
   Start Time: 1481685096
   Timeout : 300 (sec)
   Verify return code: 0 (ok)
  To clean up after running this example, remove the nginx service and the
  stored secrets.
  
  $ docker service rm nginx
  
  $ docker secret rm site.crt site.key site.conf
  Advanced example: Use secrets with a WordPress serviceIn this example, you create a single-node MySQL service with a custom root
  password, add the credentials as secrets, and create a single-node WordPress
  service which uses these credentials to connect to MySQL. The
  next example builds on this one and shows you how to
  rotate the MySQL password and update the services so that the WordPress service
  can still connect to MySQL.This example illustrates some techniques to use Docker secrets to avoid saving
  sensitive credentials within your image or passing them directly on the command
  line.
  NoteThis example uses a single-Engine swarm for simplicity, and uses a
  single-node MySQL service because a single MySQL server instance cannot be
  scaled by simply using a replicated service, and setting up a MySQL cluster is
  beyond the scope of this example.Also, changing a MySQL root passphrase isnât as simple as changing
  a file on disk. You must use a query or a mysqladmin command to change the
  password in MySQL.Generate a random alphanumeric password for MySQL and store it as a Docker
  secret with the name mysql_password using the docker secret create
  command. To make the password shorter or longer, adjust the last argument of
  the openssl command. This is just one way to create a relatively random
  password. You can use another command to generate the password if you
  choose.
  NoteAfter you create a secret, you cannot update it. You can only
  remove and re-create it, and you cannot remove a secret that a service is
  using. However, you can grant or revoke a running service's access to
  secrets using docker service update. If you need the ability to update a
  secret, consider adding a version component to the secret name, so that you
  can later add a new version, update the service to use it, then remove the
  old version.The last argument is set to -, which indicates that the input is read
  ```