instruction: Create a Dockerfile for Nginx with production best practices
output: ```dockerfile
  from 1, 2, 3 into a single patch request to the API server.
  
  Here is the live configuration that is the result of the merge:
  apiVersion: apps/v1
  kind: Deployment
  metadata:
   annotations:
   # ...
   # The annotation contains the updated image to nginx 1.16.1,
   # but does not contain the updated replicas to 2
   kubectl.kubernetes.io/last-applied-configuration: |
   {"apiVersion":"apps/v1","kind":"Deployment",
   "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
   "spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
   "spec":{"containers":[{"image":"nginx:1.16.1","name":"nginx",
   "ports":[{"containerPort":80}]}]}}}}
   # ...
  spec:
   selector:
   matchLabels:
   # ...
   app: nginx
   replicas: 2 # Set by `kubectl scale`. Ignored by `kubectl apply`.
   # minReadySeconds cleared by `kubectl apply`
   # ...
   template:
   metadata:
   # ...
   labels:
   app: nginx
   spec:
   containers:
   - image: nginx:1.16.1 # Set by `kubectl apply`
   # ...
   name: nginx
   ports:
   - containerPort: 80
   # ...
   # ...
   # ...
   # ...
  How different types of fields are merged
  How a particular field in a configuration file is merged with
  the live configuration depends on the
  type of the field. There are several types of fields:
  
  primitive: A field of type string, integer, or boolean.
  For example, image and replicas are primitive fields. Action: Replace.
  
  map, also called object: A field of type map or a complex type that contains subfields. For example, labels,
  annotations,spec and metadata are all maps. Action: Merge elements or subfields.
  
  list: A field containing a list of items that can be either primitive types or maps.
  For example, containers, ports, and args are lists. Action: Varies.
  
  When kubectl apply updates a map or list field, it typically does
  not replace the entire field, but instead updates the individual subelements.
  For instance, when merging the spec on a Deployment, the entire spec is
  not replaced. Instead the subfields of spec, such as replicas, are compared
  and merged.
  Merging changes to primitive fields
  Primitive fields are replaced or cleared.
  Note:- is used for "not applicable" because the value is not used.
  
  Field in object configuration file
  Field in live object configuration
  Field in last-applied-configuration
  Action
  
  Yes
  Yes
  -
  Set live to configuration file value.
  
  Yes
  No
  -
  Set live to local configuration.
  
  No
  -
  Yes
  Clear
  ```