1.1 Full Virtualization

a.k.a., emulation

• The host simulates everything down to and including the CPU level of the guest.
• The guest CPU can be different from that of the host.

These include the first virtualization systems (IBM 1966), often used to avoid/delay porting large application systems.

More modern instances:

• The Java Virtual Machine
• Game system emulators
• Parallels

1.2 Paravirtualization

a.k.a., OS-assisted virtualization, a.k.a., hypervisors

• CPU is not emulated, but OS is
  • Allows code between OS calls to run natively
• Many devices are simulated
• Guest CPU must be same as on host
• Guest OS can be different from that of host

Architectures:

• Hosted
• Hypervisor

1.2.1 Hosted Paravirtualization

a.k.a., type 2 hypervisor, client hypervisor

Runs the simulation as a host OS application.

• Examples:
  • VMWare
  • VirtualBox

1.2.2 Hypervisor Paravirtualization

a.k.a. type 1 hypervisor, bare metal hypervisor

The simulator is a “thin” OS sitting on top of the hardware.

• Examples
  • Xen
  • Hyper-V
  • VMWare

1.3 Containers

• Guest CPU is same as host’s
• Guest OS is same family as host’s
  • A thin OS simulation passes OS functions down to host.
• Applications are simulated

Instances:

• Docker
  • builds on OS support such as chroot
  • Oddly, docker hosted on Windows can virutalize wither Linux or Windows (but not both)

1.3.1 DockerFiles

Docker containers are defined in a dockerfile, e.g.:

Dockerfile

FROM nginx:1.10
RUN apt-get clean && apt-get update && apt-get install -y nano spawn-fcgi fcgiwrap wget curl libxml2-dev libxslt1-dev
RUN [ "apt-get", "install", "-qy", "--force-yes", \
      "perl", \
      "build-essential", \
      "cpanminus", \
      "libxml-libxslt-perl" \
      ]
RUN ["cpanm", "CGI"]
RUN ["cpanm", "LockFile::Simple"]
RUN sed -i 's/www-data/nginx/g' /etc/init.d/fcgiwrap
RUN chown nginx:nginx /etc/init.d/fcgiwrap
COPY ./vhost.conf /etc/nginx/conf.d/default.conf
COPY ./htpasswd /etc/nginx/htpasswd
WORKDIR /var/www
CMD /etc/init.d/fcgiwrap start \
    && nginx -g 'daemon off;'

• The FROM command lists a base machine definition (on DockerHub) that we use as the starting point.
  • In this case, a Linux server with an NGINX web server installed.
• The RUN and COPY commands are a script to install various additional Linux packages onto that machine and copy some web content into place.
• The CMD command launches programs to perform a computation or to start up a service.
  • In this case, starting up the web server.

1.3.2 Docker Compose

The Docker Compose facility allows you to launch a collection of separate virtual machines, each providing a specialized service, and connect them together, e.g.,

docker-compose.yml

version: '3'
services:
    web:
        container_name: web_cgi_server
        build:
            context: .

        volumes:
            - ./../build/website:/var/www
            - ./../build/log:/var/log/nginx/web
        ports:
            - "8081:80"

This launches web_cgi_server (defined in the DockerFile just shown)

• But specifies that the server will have its /var/www directory (from which web content is served) mapped onto my ../build/website directory.
• It will also write its error logs into my ../build/log directory.
• And that server, which by default listens for incoming HTTP requests on its port 80, will actually receive requests from my port 8081.

1.3.3 Infrastructure as Data

Remember that “Infrastructure as Data” was one of the defining principles of DevOps.

• Docker files and Docker compose files are plain text.
• They can be checked into a project’s version control repository.
• This means that the machines that will actually run a program are now defined in and can be created from a data file that is part of the software itself.