instruction: Create a Dockerfile for Nginx with production best practices
output: ```dockerfile
  from live configuration.
  
  No
  -
  No
  Do nothing. Keep live value.
  
  Merging changes for fields of type list
  Merging changes to a list uses one of three strategies:
  
  Replace the list if all its elements are primitives.
  Merge individual elements in a list of complex elements.
  Merge a list of primitive elements.
  
  The choice of strategy is made on a per-field basis.
  Replace the list if all its elements are primitives
  Treat the list the same as a primitive field. Replace or delete the
  entire list. This preserves ordering.
  Example: Use kubectl apply to update the args field of a Container in a Pod. This sets
  the value of args in the live configuration to the value in the configuration file.
  Any args elements that had previously been added to the live configuration are lost.
  The order of the args elements defined in the configuration file is
  retained in the live configuration.
  # last-applied-configuration value
   args: ["a", "b"]
  
  # configuration file value
   args: ["a", "c"]
  
  # live configuration
   args: ["a", "b", "d"]
  
  # result after merge
   args: ["a", "c"]
  Explanation: The merge used the configuration file value as the new list value.
  Merge individual elements of a list of complex elements:
  Treat the list as a map, and treat a specific field of each element as a key.
  Add, delete, or update individual elements. This does not preserve ordering.
  This merge strategy uses a special tag on each field called a patchMergeKey. The
  patchMergeKey is defined for each field in the Kubernetes source code:
  types.go
  When merging a list of maps, the field specified as the patchMergeKey for a given element
  is used like a map key for that element.
  Example: Use kubectl apply to update the containers field of a PodSpec.
  This merges the list as though it was a map where each element is keyed
  by name.
  # last-applied-configuration value
   containers:
   - name: nginx
   image: nginx:1.16
   - name: nginx-helper-a # key: nginx-helper-a; will be deleted in result
   image: helper:1.3
   - name: nginx-helper-b # key: nginx-helper-b; will be retained
   image: helper:1.3
  
  # configuration file value
   containers:
   - name: nginx
   image: nginx:1.16
   - name: nginx-helper-b
   image: helper:1.3
   - name: nginx-helper-c # key: nginx-helper-c; will be added in result
   image: helper:1.3
  
  # live configuration
   containers:
   - name: nginx
   image: nginx:1.16
   - name: nginx-helper-a
   image: helper:1.3
   - name: nginx-helper-b
   image: helper:1.3
   args: ["run"] # Field will be retained
   - name: nginx-helper-d # key: nginx-helper-d; will be retained
   image: helper:1.3
  
  # result after merge
   containers:
   - name: nginx
   image: nginx:1.16
   # Element nginx-helper-a was deleted
   - name: nginx-helper-b
   image: helper:1.3
   args: ["run"] # Field was retained
   - name: nginx-helper-c # Element was added
   image: helper:1.3
   - name: nginx-helper-d # Element was ignored
   image: helper:1.3
  Explanation:
  
  The container named "nginx-helper-a" was deleted because no container
  named "nginx-helper-a" appeared in the configuration file.
  The container named "nginx-helper-b" retained the changes to args
  in the live configuration. kubectl apply was able to identify
  that "nginx-helper-b" in the live configuration was the same
  "nginx-helper-b" as in the configuration file, even though their fields
  had different values (no args in the configuration file). This is
  because the patchMergeKey field value (name) was identical in both.
  The container named "nginx-helper-c" was added because no container
  with that name appeared in the live configuration, but one with
  that name appeared in the configuration file.
  The container named "nginx-helper-d" was retained because
  no element with that name appeared in the last-applied-configuration.
  
  Merge a list of primitive elements
  As of Kubernetes 1.5, merging lists of primitive elements is not supported.
  Note:Which of the above strategies is chosen for a given field is controlled by
  the patchStrategy tag in types.go
  If no patchStrategy is specified for a field of type list, then
  the list is replaced.
  Default field values
  The API server sets certain fields to default values in the live configuration if they are
  not specified when the object is created.
  Here's a configuration file for a Deployment. The file does not specify strategy:
  
  application/simple_deployment.yaml
  
  apiVersion: apps/v1
  kind: Deployment
  metadata:
   name: nginx-deployment
  spec:
   selector:
   matchLabels:
   app: nginx
   minReadySeconds: 5
   template:
   metadata:
   labels:
   app: nginx
   spec:
   containers:
   - name: nginx
   image: nginx:1.14.2
   ports:
   - containerPort: 80
  
  Create the object using kubectl apply:
  kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml
  Print the live configuration using kubectl get:
  kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
  The output shows that the API server set several fields to default values in the live
  configuration. These fields were not specified in the configuration file.
  apiVersion: apps/v1
  kind: Deployment
  # ...
  spec:
   selector:
   matchLabels:
   app: nginx
   minReadySeconds: 5
   replicas: 1 # defaulted by apiserver
   strategy:
   rollingUpdate: # defaulted by apiserver - derived
  ```