[Container] Docker And Kubernetes – Novice

• Container technology allows the packaging and isolation of applications with their entire runtime environment (all of the files necessary to run).
• A container is a unit of software that packages code with its required dependencies in order to run in an isolated, controlled environment.
  • This allows you to run an application in a way that is predictable, repeatable, and without the uncertainty of inconsistent code execution across diverse development and production environments.
  • A container will always start up and run code the same way, regardless of what machine it exists on.

• Containers and virtual machines are very similar resource virtualization technologies.
  • They wrap the software in a standardized environment that allows it to run consistently in different environments.
• The key differentiator between containers and virtual machines:
  • Virtual Machines virtualize an entire machine down to the hardware layers.
  • Containers only virtualize software layers above the operating system level.
    • Containers are more lightweight than VMs – less resources usage.
    • Faster than VMs – Container can start up in seconds, not minutes.
    • Smaller than VMs – Container images can be measured in megabytes, not gigabytes.
    • In short, Containers are faster, use fewer resources, and easier to automate.

• Software Portability
  • Easy to move the contained application between environments (dev, test, production, etc.) while retaining full functionality.
  • The contained application runs quickly and reliably development, testing, and production
• Isolation
  • Although containers share the same operating system kernel, but the application processes are isolated from the rest of the system.
  • This keeps individual pieces of software separate from one another.
• Security
  • While the container’s isolation is great for security.
  • Containers can also improve the security elements by building security into the container pipeline and defending the infrastructure.
• Automation
  • Containers are flexible, lightweight and quick, therefore automation is much easier to build around containers than it is around other technologies (such as VMs).
• Scalable
  • Containers are so flexible, fast, and able to scale up/down in real time as needed.
• Fast and Efficient
  • Containers are lightweight, portable and easy to automate, these provide the opportunity for faster development and meeting business needs as they arise.
  • Containers are highly efficient, they use less resources compared to other technologies (such as VMs), therefore save cost.

• Containers share the same OS kernel, therefore:
  • Less flexibility than VMs – You can’t run a Windows container on a Linux machine (yet).
  • Less secure than VMs – shared host exploits.
• Containers introduce new challenges around orchestration and automation.

• Operating System: This is the software that manages all other software on your computer, along with the hardware. Examples:
  • Linux, which itself has many distributions such as Red hat, Ubuntu.
  • Windows 10, Windows 11.
• Kernel: This is the component of the OS that specializes in the most basic, low-level interfacing with a machine’s hardware.
  • It translates the requests for physical resources between software processes and the hardware.
  • Resources include compute power from the CPU, memory allocation from RAM, and I/O from the hard disk.

• Container Image: These are packages of software required by containers that contain the code, runtime, system libraries, and dependencies. Usually they start from an image of an OS like Ubuntu. These images can be built manually, or can be retrieved from an image registry.
  • Image Registry: This is a solution for container image storage and sharing. The most prominent example is Docker Hub, but alternative public image registries exist and private image registries can be implemented.
  • Image Repository: This is a specific location for a container image within an image registry. It contains the latest image along with the history of it within a registry.

• Container runtime: This manages the start up and existence of a container, along with how a container actually executes code.
  • Container runtimes themselves are divided into two groups:
    • Open Container Initiative (OCI): This is the baseline runtime that creates and runs a container, examples:
      • runc, which is the most common, used by Docker, and written in Golang.
      • An alternative is crun from Red Hat written in C, and is meant to be faster and lightweight.
    • Container Runtime Interface (CRI): This runtime is more focused on container orchestration, examples:
      • dockershim, which has steadily been dropped.
      • containerd, from Docker, which has more features.
      • Other alternative is CRI-O, from Red Hat.

• Container engines: Complete solutions for container technologies, these include:
  • The container, the container runtime underlying it, the container image and the tools to build them, and potentially can include container image registries and container orchestration.
  • Most container engines use a combination of runtimes:
    • OCI runtime: runc
    • CRI runtime: containerd
  • Docker is currently the industry leader in container engines.
  • Docker alternatives:
    • Red Hat’s solution stack:
      • Podman: manages the runtime of containers.
      • Buildah: builds container images.
      • Skopeo: an interface between container images and image registries.
• Container Orchestration: Automation of container deployment. Orchestration involves provisioning, configuration, scheduling, scaling, monitoring, deployment, and more.
  • Kubernetes is currently the industry leading container orchestration tool.
  • Kubernetes alternatives:
    • Docker Swarm: docker’s native container orchestration solution.
    • Marathon: based on Apache mesos, offers APIs for integrating with other tools.
    • Nomad: open source built by HashiCorp, designed to be simple and lightweight.

• I want to start up a set of 5 containers in production.
  • I could spin up each container manually.
  • Or, I could tell an orchestration tool like Kubernetes that I want five containers, and let the tool do it.
• I want to make sure the 5 containers are on 5 different hosts (for redundancy’s sake).
  • This more complex requirement requires additional work in order to ensure that those 5 containers are running on different hosts.
  • The more complex those requirements become for managing my containers, the more useful orchestration tools are going to be in order to make that process easier.

• In the old days, deployments went like this:
  • Take the server down for maintenance (it is unavailable to customers).
  • Perform the deployment.
  • Bring the server back up.
• A zero-downtime deployment (with containers) goes like this.
  • Spin up containers running the new code.
  • When they are fully up, direct user traffic to the new containers.
  • Remove the old containers running the old code (No downtime for users).
• Orchestration tools help to coordinate those steps quickly and efficiently.

• Container orchestration tool is a software that allow you to easily build and manage container infrastructure and automation.
• Kubernetes is currently the industry leading container orchestration tool.
  • It allows things like self-healing application, automated scaling, and easy automated deployments.
• Kubernetes alternatives:
  • Docker Swarm: docker’s native container orchestration solution.
  • Marathon: based on Apache mesos, offers APIs for integrating with other tools.
  • Nomad: open source built by HashiCorp, designed to be simple and lightweight.

• Cloud providers offer built-in container orchestration solutions, including cloud-native Kubernetes implementation.
• For example:
  • Amazon ECS (Elastic Container Services)
  • Amazon ECS for Kubernetes
  • Azure Kubernetes Service
  • Google Kubernetes Engine

LTM Objects

## app-service /Common/sslo_demoL3.app/sslo_demoL3 ##
/Common/sslo_demoL3.app
ltm virtual sslo_demoL3-in-t-4 {
ltm virtual sslo_demoL3-in-u-4 {
ltm virtual sslo_demoL3-ot-4 {

ltm virtual sslo_demoL3-in-t-4 {
    app-service /Common/sslo_demoL3.app/sslo_demoL3
    destination /Common/0.0.0.0:any
    ip-protocol tcp
    mask any
## ltm/apm profile ##
    per-flow-request-access-policy /Common/ssloP_demoL3.app/ssloP_demoL3_per_req_policy
    profiles {
        /Common/f5-tcp-wan {
            context serverside
        }
        /Common/ssloT_demoL3.app/ssloT_demoL3-cssl {
            context clientside
        }
        /Common/ssloT_demoL3.app/ssloT_demoL3-sssl {
            context serverside
        }
        sslo_demoL3-http { }
        sslo_demoL3-http-proxy-connect { }
        sslo_demoL3-tcp-lan {
            context clientside
        }
        sslo_demoL3_accessProfile { }
    }
## ltm rule ##
    rules {
        sslo_demoL3-in_t
        sslo_demoL3-lib
        /Common/ssloS_FEYE.app/ssloS_FEYE-port_remap
        /Common/ssloS_IPS.app/ssloS_IPS-port_remap
    }
## ltm pool ##
    pool sslo_demoL3-ex-pool-4
## etc ##
    serverssl-use-sni disabled
    source 0.0.0.0/0
    source-address-translation {
        type automap
    }
    translate-address disabled
    translate-port disabled
    vlans {
        /Common/client-vlan
    }
    vlans-enabled
}

## ltm profile ## 
/Common
ltm profile tcp f5-tcp-wan {

/Common/sslo_demoL3.app
ltm profile tcp sslo_demoL3-tcp-lan {
ltm profile http sslo_demoL3-http {
ltm profile http-proxy-connect sslo_demoL3-http-proxy-connect {

/Common/ssloT_demoL3.app
ltm profile client-ssl ssloT_demoL3-cssl {
ltm profile server-ssl ssloT_demoL3-sssl {

## apm profile ##
/Common/sslo_demoL3.app
apm profile access sslo_demoL3_accessProfile {

/Common/ssloP_demoL3.app
apm policy access-policy ssloP_demoL3_per_req_policy {

## ltm rule ##
/Common/sslo_demoL3.app
ltm rule sslo_demoL3-in_t {
ltm rule sslo_demoL3-lib {

/Common/ssloS_FEYE.app
ltm rule ssloS_FEYE-port_remap {

/Common/ssloS_IPS.app
ltm rule ssloS_IPS-port_remap {

## ltm pool ## 
ltm pool sslo_demoL3-ex-pool-4 {
    app-service /Common/sslo_demoL3.app/sslo_demoL3
    members {
        /Common/10.1.20.1:any {
            address 10.1.20.1
            session monitor-enabled
            state up
        }
    }
    min-active-members 1
    monitor min 1 of { /Common/gateway_icmp }
    slow-ramp-time 300
}

APM Objects

apm profile access sslo_demoL3_accessProfile {
    access-policy sslo_demoL3_accessPolicy
    app-service /Common/sslo_demoL3.app/sslo_demoL3
## log-settings ##
    log-settings {
        sslo_demoL3-log-setting
    }
    type ssl-orchestrator
## apm policy customization-group ##    
    customization-group sslo_demoL3_logout
    eps-group sslo_demoL3_unknown_customization
    errormap-group sslo_demoL3_errormap
    framework-installation-group sslo_demoL3_framework_installation
    general-ui-group sslo_demoL3_general_ui
}

apm policy access-policy sslo_demoL3_accessPolicy {
    app-service /Common/sslo_demoL3.app/sslo_demoL3
    caption general
## apm policy policy-item ##
    default-ending sslo_demoL3_end_allow
    items {
        sslo_demoL3_end_allow { }
        sslo_demoL3_ent { }
    }
    start-item sslo_demoL3_ent
}

## apm log-settings ##
/Common/sslo_demoL3.app
apm log-setting sslo_demoL3-log-setting {
    access { general-log { log-level {..}
            publisher /Common/sys-sslo-publisher
            type ssl-orchestrator } }
    url-filters { urlf { publisher /Common/sys-sslo-publisher } }
}

## apm policy customization-group ## 
/Common/sslo_demoL3.app
apm policy customization-group sslo_demoL3_errormap {
apm policy customization-group sslo_demoL3_framework_installation {
apm policy customization-group sslo_demoL3_general_ui {
apm policy customization-group sslo_demoL3_logout {
apm policy customization-group sslo_demoL3_unknown_customization {

## apm policy policy-item ##
/Common/sslo_demoL3.app
apm policy policy-item sslo_demoL3_end_allow {
apm policy policy-item sslo_demoL3_ent {
apm policy agent ending-allow sslo_demoL3_end_allow_ag {