To create a strongly-typed class for binding to a configuration section:

• The property names and their types match the key names and their value types "exactly" in the configuration.
• The classes used must be non-abstract with parameterless constructors
• Only the public accessors (properties) are bound to configuration data but not fields

A Configuration section can be bound to a strictly-typed class object in two ways:

• use Configuration.Bind() by passing the configuration section to bind and the object to which the values are mapped.
• use services.Configure() to bind a section to a type and access the type by means of IOptions, IOptionsSnapshot or IOptionMonitor interface.

IOptionsMonitor returns the "CurrentValue" of the options along with notifications when the options change.

• It is created as a SingletonService which can be injected into any service
• It also supports updated options when the configuration changes after app starts
• It also supports "named" options

Named options are when a single class is to be used for creating different objects of configurations that have the same structure.

IOptions:

• Options configured in IOptions are registered as SingletonServices
• Can be injected into any service for accessing options
• Doesn't support option updates when configuration changes
• Doesn't support Named options

IOptionsSnapshot:

• Options configured in IOptionsSnapshot are registered as ScopedServices
• Can be injected into only Scoped and Transient services
• Supports updated options even after configuration is loaded
• Supports Named options

To view logs for running containers, we can use LOG command.

  > docker logs --follow

The --follow flag will continue streaming the new output from the container's STDOUT and STDERR onto the terminal.

docker restart policies dictate how a container should behave when it is shutted down by some factor.

There are four restart-policies:

• No - Never restart when stopped by some means
• Always - Always restart no matter how it is stopped
• On-Failure - Restart only when the container stops with an erroneous code
• Unless-Stopped - Restart always unless stopped manually with a KILL or STOP

Port Mapping is a term used to link a specific port within the container where the application is presumed to be running to a port of the host system where the container is running. Since docker runs containers in an isolated virtual environment, it is not possible for the user to directly access the port within a docker container from outside. By mapping ports, we instruct docker to pass all the requests to a specific host port to a port inside the container.

> docker run -p <host_port>:<container_port> <container_id>

Example:

> docker run -p 8080:80 nginx

The services section in a docker-compose file is an array of containers which are to be built and run together when the docker-compose file is executed. Each container under a docker-compose file is indicated with a user specific "service_name" which is used by other containers for communication among themselves. These "service names" need to be unique within a docker-compose file and are auto resolved for their respective containers by the docker.

version: '3'
services: 
    redis-server:
        build: .
        ports:
            - 8000:6379
     angular-app:
        build: .
        ports:
            - 8080:80

A Dockerfile is a set of instructions about how a container for an application shall be built from the scratch using a base image. A docker-compose is a yaml script which comprises of how multiple docker containers grouped under a single subnet shall be built and run.

A docker-compose file runs on top of a Dockerfile and requires a path for the Dockerfile to be specified in the script for custom containers.

A docker-compose is a command which comes out of the box along with the docker installation, that helps in keeping instructions to run a container out of an image simple without missing out on any instruction which needs to be passed on while creating a container. A Docker-compose file is a yaml script, which contains an elaborated set of instructions about how to build and run a docker container.

A Dockerfile can be built and run in the same way a normal container is created and run.

> docker build -t <docker_hub_user_id>/<repository_name>[:version_tag] <path_to_dockerfile>

Where -t refers to an image_tag: a unique readable name assigned to the created image by the developer for future references.

Example:

> docker build -t refebruvuser/mynpm .

And is run as:

> docker run -i -t <docker_hub_user_id>/<repository_name>[:version_tag]

A Dockerfile is a file of same name with no extension. It typically contains three parts or steps in which a container shall be built.

1. Specify a base Image
2. Instructions on how to build and deploy the application onto the base Image
3. A Startup command to specify how the container should behave once started

A Dockerfile is a configuration file which contains instructions for docker on how to build a customized image from an existing base image and how to get things started. It can be treated as a build script for a docker container.

docker PS command gives user the ability to monitor all the created containers in the system.

> docker ps

Command shows all the containers which are currently running in the system. Adding an -a flag to the command shows all the containers which are available in the system (both running and stopped).