Docker image

Docker Image Resource

Tracks and builds Docker images.

Note: docker registry must be v2.

Source Configuration

  • : Required. The name of the repository, e.g. .

    Note: When configuring a private registry which requires a login, the registry's address must contain at least one '.' e.g. or contain the port (e.g. or ). Otherwise docker hub will be used.

    Note: When configuring a private registry using a non-root CA, you must include the port (e.g. :443 or :5000) even though the docker CLI does not require it.

  • : Optional. The tag to track. Defaults to .

  • : Optional. The username to authenticate with when pushing.

  • : Optional. The password to use when authenticating.

  • : Optional. AWS access key to use for acquiring ECR credentials.

  • : Optional. AWS secret key to use for acquiring ECR credentials.

  • : Optional. AWS session token (assumed role) to use for acquiring ECR credentials.

  • : Optional. An array of CIDRs or addresses to whitelist for insecure access (either or unverified ). This option overrides any entries in with the same address.

  • : Optional. A URL pointing to a docker registry mirror service.

    Note: is ignored if contains an explicitly-declared registry-hostname-prefixed value, such as , in which case the registry cited in the value is used instead of the .

  • : Optional. An array of objects with the following format:

    ca_certs: - domain: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE------ domain: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----

    Each entry specifies the x509 CA certificate for the trusted docker registry residing at the specified domain. This is used to validate the certificate of the docker registry when the registry's certificate is signed by a custom authority (or itself).

    The domain should match the first component of , including the port. If the registry specified in does not use a custom cert, adding will break the check script. This option is overridden by entries in with the same address or a matching CIDR.

  • : Optional. An array of objects with the following format:

    client_certs: - domain: example.comcert: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----key: | -----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY------ domain: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----key: | -----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY-----

    Each entry specifies the x509 certificate and key to use for authenticating against the docker registry residing at the specified domain. The domain should match the first component of .

  • : Optional. Maximum concurrent downloads.

    Limits the number of concurrent download threads.

  • : Optional. Maximum concurrent uploads.

    Limits the number of concurrent upload threads.


: Check for new images.

The current image digest is fetched from the registry for the given tag of the repository.

: Fetch the image from the registry.

Pulls down the repository image by the requested digest.

The following files will be placed in the destination:

  • : If is , the d image will be provided here.
  • : The name of the repository that was fetched.
  • : The tag of the repository that was fetched.
  • : The fetched image ID.
  • : The fetched image digest.
  • : If is , the contents of the image will be provided here.
  • : Collects custom metadata. Contains the container variables and running .
  • : Output of the on . Useful if collecting metadata from your image.


  • : Optional. Place a d image in the destination.
  • : Optional. Place a file of the image in the destination.
  • : Optional. Skip of image. Artifacts based on the image will not be present.

As with all concourse resources, to modify params of the implicit step after each step you may also set these parameters under a . For example:

put: fooparams: {...}get_params: {skip_download: true}

: Push an image, or build and push a .

Push a Docker image to the source's repository and tag. The resulting version is the image's digest.


  • : Optional. Path to a file containing a whitespace-separated list of tags. The Docker build will additionally be pushed with those tags.

  • : Optional. The path of a directory containing a to build.

  • : Optional. A map of Docker build-time variables. These will be available as environment variables during the Docker build.

    While not stored in the image layers, they are stored in image metadata and so it is recommend to avoid using these to pass secrets into the build context. In multi-stage builds s in earlier stages will not be copied to the later stages, or in the metadata of the final stage.

    The build metadata environment variables provided by Concourse will be expanded in the values (the syntax is or ).


    build_args: DO_THING: trueHOW_MANY_THINGS: 2EMAIL: [email protected]_BUILD_ID: concourse-$BUILD_ID
  • : Optional. Path to a JSON file containing Docker build-time variables.

    Example file contents:

    { "EMAIL": "[email protected]", "HOW_MANY_THINGS": 1, "DO_THING": false }
  • : Optional. Default . When the parameter is set, first pull from the Docker registry (so as to use cached intermediate images when building). This will cause the resource to fail if it is set to and the image does not exist yet.

  • : Optional. An array of images to consider as cache, in order to reuse build steps from a previous build. The array elements are paths to directories generated by a step with . This has a similar aim of , but it loads the images from disk instead of pulling them from the network, so that Concourse resource caching can be used. It also allows more than one image to be specified, which is useful for multi-stage Dockerfiles. If you want to cache an image used in a step, you should put it in instead.

  • : Optional. Default . The specific tag to pull before building when parameter is set. Instead of pulling the same tag that's going to be built, this allows picking a different tag like or the previous version. This will cause the resource to fail if it is set to a tag that does not exist yet.

  • : Optional. The path of the in the directory if it's not at the root of the directory.

  • : Optional. This enables a Docker BuildKit build. The value should be set to 1 if applicable.

  • : Optional. A path to a file to and then push.

  • : Optional. A map of labels that will be added to the image.


    labels: commit: b4d4823version: 1.0.3
  • : Optional. Path to a JSON file containing the image labels.

    Example file contents:

    { "commit": "b4d4823", "version": "1.0.3" }
  • : Optional. The path of a directory containing an image that was fetched using this same resource type with .

  • : Optional. A path to a directory containing an image to before running . The directory must have , , , and present, i.e. the tree produced by .

  • : Optional. Same as , but takes an array to load multiple images.

  • : Optional. A path to a file to and then push. Requires .

  • : Optional. The repository of the image loaded from .

  • : Optional. Default . The tag of image loaded from

  • : Optional.DEPRECATED. Use and instead. A path to a repository to pull down, and then push to this resource.

  • : Optional.DEPRECATED. Use and instead. Default . The tag of the repository to pull down via .

  • : DEPRECATED - Use instead

  • : Optional. The value should be a path to a file containing the name of the tag. When not set, the Docker build will be pushed with tag value set by in source configuration.

  • : Optional. Default . If true, the pushed image will be tagged as in addition to whatever other tag was specified.

  • : Optional. If specified, the tag read from the file will be prepended with this string. This is useful for adding in front of version numbers.

  • : Optional. Specify the name of the target build stage. Only supported for multi-stage Docker builds


resources: - name: git-resourcetype: gitsource: # ... - name: git-resource-imagetype: docker-imagesource: repository: concourse/git-resourceusername: usernamepassword: password - name: git-resource-rootfstype: s3source: # - name: build-rootfsplan: - get: git-resource - put: git-resource-imageparams: {build: git-resource}get_params: {rootfs: true} - put: git-resource-rootfsparams: {file: git-resource-image/rootfs.tar}



  • golang is required - version 1.9.x is tested; earlier versions may also work.
  • docker is required - version 17.06.x is tested; earlier versions may also work.

Running the tests

The tests have been embedded with the ; ensuring that the testing environment is consistent across any enabled platform. When the docker image builds, the test are run inside the docker container, on failure they will stop the build.

Run the tests with the following commands for both and images:

docker build -t docker-image-resource -f dockerfiles/alpine/Dockerfile . docker build -t docker-image-resource -f dockerfiles/ubuntu/Dockerfile --build-arg base_image=ubuntu:latest .

To use the newly built image, push it to a docker registry that's accessible to Concourse and configure your pipeline to use it:

resource_types: - name: docker-image-resourcetype: docker-imageprivileged: truesource: repository: latestresources: - name: some-imagetype: docker-image-resource...


Please make all pull requests to the branch and ensure tests pass locally.


Quick reference

(See "What's the difference between 'Shared' and 'Simple' tags?" in the FAQ.)

Simple Tags

  • , , , ,
  • , , , ,
  • , , ,
  • , , ,
  • , , ,

Shared Tags

Although running Docker inside Docker is generally not recommended, there are some legitimate use cases, such as development of Docker itself.

Docker is an open-source project that automates the deployment of applications inside software containers, by providing an additional layer of abstraction and automation of operating-system-level virtualization on Linux, Mac OS and Windows.


Before running Docker-in-Docker, be sure to read through Jérôme Petazzoni's excellent blog post on the subject, where he outlines some of the pros and cons of doing so (and some nasty gotchas you might run into).

If you are still convinced that you need Docker-in-Docker and not just access to a container's host Docker server, then read on.



Starting in 18.09+, the variants of this image will automatically generate TLS certificates in the directory specified by the environment variable.

Warning: in 18.09, this behavior is disabled by default (for compatibility). If you use , shared network namespaces (as in Kubernetes pods), or otherwise have network access to the container (including containers started within the instance via their gateway interface), this is a potential security issue (which can lead to access to the host system, for example). It is recommended to enable TLS by setting the variable to an appropriate value ( or similar). In 19.03+, this behavior is enabled by default.

When enabled, the Docker daemon will be started with (and when disabled, the Docker daemon will be started with ).

Inside the directory specified by , the entrypoint scripts will create/use three directories:

  • : the certificate authority files (, )
  • : the (daemon) certificate files (, , )
  • : the (client) certificate files (, , ; suitable for )

In order to make use of this functionality from a "client" container, at least the subdirectory of the directory needs to be shared (as illustrated in the following examples).

To disable this image behavior, simply override the container command or entrypoint to run directly ( or ).

Start a daemon instance

Note: is required for Docker-in-Docker to function properly, but it should be used with care as it provides full access to the host environment, as explained in the relevant section of the Docker documentation.

Connect to it from a second container

Custom daemon flags

Runtime Settings Considerations

Inspired by the official systemd configuration, you may want to consider different values for the following runtime configuration options, especially for production Docker instances:

Some of these will not be supported based on the settings on the host's , such as , giving errors that look like , and some may inherit sane values from the host instance or may not apply for your usage of Docker-in-Docker (for example, you likely want to set to a value that's higher than on the host so that your Docker-in-Docker instance is killed before the host Docker instance is).


For more information about using the experimental "rootless" image variants, see docker-library/docker#174.

Note: just like the regular images, is required for Docker-in-Docker to function properly (docker-library/docker#151 & docker-library/docker#281). For rootless images, an argument of is required for (docker/docker#40759).

Basic example usage:

Where to Store Data

Important note: There are several ways to store data used by applications that run in Docker containers. We encourage users of the images to familiarize themselves with the options available, including:

  • Let Docker manage the storage of your data by writing to disk on the host system using its own internal volume management. This is the default and is easy and fairly transparent to the user. The downside is that the files may be hard to locate for tools and applications that run directly on the host system, i.e. outside containers.
  • Create a data directory on the host system (outside the container) and mount this to a directory visible from inside the container. This places the files in a known location on the host system, and makes it easy for tools and applications on the host system to access the files. The downside is that the user needs to make sure that the directory exists, and that e.g. directory permissions and other security mechanisms on the host system are set up correctly.

The Docker documentation is a good starting point for understanding the different storage options and variations, and there are multiple blogs and forum postings that discuss and give advice in this area. We will simply show the basic procedure here for the latter option above:

  1. Create a data directory on a suitable volume on your host system, e.g. .

  2. Start your container like this:

The part of the command mounts the directory from the underlying host system as inside the container, where Docker by default will write its data files.

The images come in many flavors, each designed for a specific use case.

This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.

This image is based on Windows Server Core (). As such, it only works in places which that image does, such as Windows 10 Professional/Enterprise (Anniversary Edition) or Windows Server 2016.

For information about how to get Docker running on Windows, please see the relevant "Quick Start" guide provided by Microsoft:

View license information for the software contained in this image.

As with all Docker images, these likely also contain other software which may be under other licenses (such as Bash, etc from the base distribution, along with any direct or indirect dependencies of the primary software being contained).

Some additional license information which was able to be auto-detected might be found in the repository's directory.

As for any pre-built image usage, it is the image user's responsibility to ensure that any use of this image complies with any relevant licenses for all software contained within.

  1. Pixelmon charmander
  2. Fire and ice wolf tattoo
  3. Lotr mod
  4. Dad clipart

A Beginner’s Guide to Understanding and Building Docker Images

Edward Kisller
2021-05-04 11:24


User-added image


Last updated: Mar. 17, 2021

A Docker image is a read-only template that contains a set of instructions for creating a container that can run on the Docker platform. It provides a convenient way to package up applications and preconfigured server environments, which you can use for your own private use or share publicly with other Docker users. Docker images are also the starting point for anyone using Docker for the first time.

So, in this introduction, we’ll not only take you through the basics of Docker images, but also show you where to find ready-made, off-the-shelf images that will give you a head start in building your own containerized applications, tools, and services.

As a new Docker user, you’ll also need to understand how to build your own custom images. So, we’ll briefly cover how to create Docker images for deploying your code and assembling container-based services. But first let’s look at the composition of a Docker image in more detail.

Set Up Your Own Free Docker Registry

Anatomy of a Docker Image

A Docker image is made up of a collection of files that bundle together all the essentials – such as installations, application code, and dependencies – required to configure a fully operational container environment. You can create a Docker image by using one of two methods:

  • Interactive: By running a container from an existing Docker image, manually changing that container environment through a series of live steps, and saving the resulting state as a new image.
  • Dockerfile: By constructing a plain-text file, known as a Dockerfile, which provides the specifications for creating a Docker image.

We’ll cover these two methods in more detail later in this guide. For now, though, let’s focus on the most important Docker image concepts.

Image Layers

Each of the files that make up a Docker image is known as a layer. These layers form a series of intermediate images, built one on top of the other in stages, where each layer is dependent on the layer immediately below it. The hierarchy of your layers is key to efficient lifecycle management of your Docker images. Thus, you should organize layers that change most often as high up the stack as possible. This is because, when you make changes to a layer in your image, Docker not only rebuilds that particular layer, but all layers built from it. Therefore, a change to a layer at the top of a stack involves the least amount of computational work to rebuild the entire image.

Container Layer

Each time Docker launches a container from an image, it adds a thin writable layer, known as the container layer, which stores all changes to the container throughout its runtime. As this layer is the only difference between a live operational container and the source Docker image itself, any number of like-for-like containers can potentially share access to the same underlying image while maintaining their own individual state.User-added image

Containers based on the same image share that image, reducing resource overhead

Parent Image

In most cases, the first layer of a Docker image is known as the parent image. It’s the foundation upon which all other layers are built and provides the basic building blocks for your container environments. You can find a wide variety of ready-made images for use as your parent image on the public container registry Docker Hub. You can also find them on a small number of third-party services, such as the Google Container Registry. Alternatively, you can use one of your own existing images as the basis for creating new ones.

A typical parent image may be a stripped-down Linux distribution or come with a preinstalled service, such as a database management system (DBMS) or a content management system (CMS).

Base Image

In simple terms, a base image is an empty first layer, which allows you to build your Docker images from scratch. Base images give you full control over the contents of images, but are generally intended for more advanced Docker users.

Docker Manifest

Together with a set of individual layer files, a Docker image also includes an additional file known as a manifest. This is essentially a description of the image in JSON format and comprises information such as image tags, a digital signature, and details on how to configure the container for different types of host platforms.User-added image

Container Registries

Container registries are catalogs of storage locations, known as repositories, where you can push and pull container images. The three main registry types are:

  • Docker Hub: Docker’s own, official image resource where you can access more than 100,000 container images shared by software vendors, open-source projects, and Docker’s community of users. You can also use the service to host and manage your own private images.
  • Third-party registry services: Fully managed offerings that serve as a central point of access to your own container images, providing a way to store, manage, and secure them without the operational headache of running your own on-premises registry. Examples of third-party registry offerings that support Docker images include Red Hat Quay, Amazon ECR, Azure Container Registry, Google Container Registry, and the JFrog Container Registry.
  • Self-hosted registries: A registry model favored by organizations that prefer to host container images on their own on-premises infrastructure – typically due to security, compliance concerns or lower latency requirements. To run your own self-hosted registry, you’ll need to deploy a registry server. Alternatively, you can set up your own private, remote, and virtual Docker registry.


Get started with JFrog Artifactory for FREE and manage Docker containers

Take the Docker challenge


Container Repositories

Container repositories are the specific physical locations where your Docker images are actually stored, whereby each repository comprises a collection of related images with the same name. Each of the images within a repository is referenced individually by a different tag and represents a different version of fundamentally the same container deployment. For example, on Docker Hub, mysql is the name of the repository that contains different versions of the Docker image for the popular, open-source DBMS, MySQL.

How to Create a Docker Image

In this final section, we’ll cover the two different methods of creating Docker images in a little more detail, so you can start putting your knowledge into practice.

Interactive Method

Advantages: Quickest and simplest way to create Docker images. Ideal for testing, troubleshooting, determining dependencies, and validating processes.

Disadvantages: Difficult lifecycle management, requiring error-prone manual reconfiguration of live interactive processes. Easier to create unoptimized images with unnecessary layers.

The following is a set of simplified steps to creating an image interactively:

  • Install Docker and launch the Docker engine
  • Open a terminal session
  • Use the following Docker run command to start an interactive shell session with a container launched from the image specified by image_name:tag_name:

 $ docker run -it image_name:tag_name bash

If you omit the tag name, then Docker automatically pulls the most recent image version, which is identified by the latest tag. If Docker cannot find the image locally then it will pull what it needs to build the container from the appropriate repository on Docker Hub.

In our example, we’ll launch a container environment based on the latest version of Ubuntu:

 $ docker run -it ubuntu bash

  • Now configure your container environment by, for example, installing all the frameworks, dependencies, libraries, updates, and application code you need. The following simple example adds an NGINX server:

 # apt-get update && apt-get install -y nginx

Next, you’ll need to know the name or ID of your running container instance.

  • Open another Bash shell and type the following docker ps command to list active container processes:

 $ docker ps

The sample output below shows our running container with the ID e61e8081866d and the name keen_gauss:


e61e8081866d    ubuntu    “bash”  2 minutes ago     Up 2 minutes         keen_gauss

This name is randomly generated by the Docker daemon. But you can also identify your container with something more meaningful by assigning your own name using the – name operator in the Docker run command.

  • Save your image using the Docker commit command, specifying either the ID or name of the container from you which want to create it:

 $ docker commit keen_gauss ubuntu_testbed

In the example above, we supplied the name of our container and called the resulting image ubuntu_testbed.

  • Now, use the Docker images command to see the image you’ve just created:

 $ docker images

You should see your new image listed in the results.

REPOSITORY     TAG        IMAGE ID          CREATED            SIZE
ubuntu        latest      775349758637      5 minutes ago      64.2MB

  • Finally, return to your interactive container shell and type exit to shut it down.

 # exit

Dockerfile Method

Advantages: Clean, compact and repeatable recipe-based images. Easier lifecycle management and easier integration into continuous integration (CI) and continuous delivery (CD) processes. Clear self-documented record of steps taken to assemble the image.

Disadvantages: More difficult for beginners and more time consuming to create from scratch.

The Dockerfile approach is the method of choice for real-world, enterprise-grade container deployments. It’s a more systematic, flexible, and efficient way to build Docker images and the key to compact, reliable, and secure container environments.

In short, the Dockerfile method is a three-step process whereby you create the Dockerfile and add the commands you need to assemble the image.

The following table shows you those Dockerfile statements you’re most likely to use:




To specify the parent image.


To set the working directory for any commands that follow in the Dockerfile.


To install any applications and packages required for your container.


To copy over files or directories from a specific location.


As COPY, but also able to handle remote URLs and unpack compressed files.


Command that will always be executed when the container starts. If not specified, the default is /bin/sh -c


Arguments passed to the entrypoint. If ENTRYPOINT is not set (defaults to /bin/sh -c), the CMD will be the commands the container executes.


To define which port through which to access your container application.


To add metadata to the image.

Example Dockerfile

# Use the official Ubuntu 18.04 as base
FROM ubuntu:18.04
# Install nginx and curl
RUN apt-get update &&
apt-get upgrade -y &&
apt-get install -y nginx curl &&
rm -rf /var/lib/apt/lists/*

An example of a Dockerfile for building an image based on official Ubuntu 18.04 with installing Nginx

Next, we’ll set up a .dockerignore file to list any files that would otherwise be created during the Docker build process, which you want to exclude from the final build.

.dockerignore files play an important role in creating more compact, faster-running containers – by providing a way to prevent sensitive or unnecessary files and directories from making their way into your image builds. Your .dockerignore file should be located in the root directory, known as the build context, from which you intend to build your image. This will be either your current working directory or the path you specify in the Docker build command that we’ll discuss below.

User-added image

The Docker Build Context

Now use the Docker build command to create your Docker image. Use the -t flag to set an image name and tag:

$ docker build -t my-nginx:0.1 .

In the example above, we built the image from within the same directory as the Dockerfile and the context, as the . argument simply tells the Docker daemon to build the image from the files and folders in the current working directory.

Finally, as we saw in the interactive method, you can use the Docker images command to see the image you’ve just created.

 $ docker images


my-nginx       0.1 f95ae2e1344b    10 seconds ago 138MB

ubuntu         18.04 ccc6e87d482b  12 days ago 64.2MB

Again, you should see your new image listed in the results.

Learn more about Docker:


docker images


List images


Extended description

The default will show all top level images, their repository and tags, and their size.

Docker images have intermediate layers that increase reusability, decrease disk usage, and speed up by allowing each step to be cached. These intermediate layers are not shown by default.

The is the cumulative space taken up by the image and all its parent images. This is also the disk space used by the contents of the Tar file created when you an image.

An image will be listed more than once if it has multiple repository names or tags. This single image (identifiable by its matching ) uses up the listed only once.

For example uses of this command, refer to the examples section below.


Name, shorthandDefaultDescription
, Show all images (default hides intermediate images)
Show digests
, Filter output based on conditions provided
Pretty-print images using a Go template
Don't truncate output
, Only show image IDs


List the most recently created images

List images by name and tag

The command takes an optional argument that restricts the list to images that match the argument. If you specify but no , the command lists all images in the given repository.

For example, to list all images in the “java” repository, run this command :

The value must be an “exact match”. This means that, for example, does not match the image .

If both and are provided, only images matching that repository and tag are listed. To find all local images in the “java” repository with tag “8” you can use:

If nothing matches , the list is empty.

List the full length image IDs

List image digests

Images that use the v2 or later format have a content-addressable identifier called a . As long as the input used to generate the image is unchanged, the digest value is predictable. To list image digest values, use the flag:

When pushing or pulling to a 2.0 registry, the or command output includes the image digest. You can using a digest value. You can also reference by digest in , , and commands, as well as the image reference in a Dockerfile.


The filtering flag ( or ) format is of “key=value”. If there is more than one filter, then pass multiple flags (e.g., )

The currently supported filters are:

  • dangling (boolean - true or false)
  • label ( or )
  • before (, or ) - filter images created before given id or references
  • since (, or ) - filter images created since given id or references
  • reference (pattern of an image reference) - filter images whose reference matches the specified pattern

Show untagged images (dangling)

This will display untagged images that are the leaves of the images tree (not intermediary layers). These images occur when a new build of an image takes the away from the image ID, leaving it as or untagged. A warning will be issued if trying to remove an image when a container is presently using it. By having this flag it allows for batch cleanup.

You can use this in conjunction with :

Docker warns you if any containers exist that are using these untagged images.

Show images with a given label

The filter matches images based on the presence of a alone or a and a value.

The following filter matches images with the label regardless of its value.

The following filter matches images with the label with the value.

In this example, with the value, it returns an empty set because no matches were found.

Filter images by time

The filter shows only images created before the image with given id or reference. For example, having these images:

Filtering with would give:

Filtering with would give:

Filter images by reference

The filter shows only images whose reference matches the specified pattern.

Filtering with would give:

Filtering with multiple would give, either match A or B:

Format the output

The formatting option () will pretty print container output using a Go template.

Valid placeholders for the Go template are listed below:

Image ID
Image repository
Image tag
Image digest
Elapsed time since the image was created
Time when the image was created
Image disk size

When using the option, the command will either output the data exactly as the template declares or, when using the directive, will include column headers as well.

The following example uses a template without headers and outputs the and entries separated by a colon () for all images:

To list all images with their repository and tag in a table format you can use:

Parent command

dockerThe base command for the Docker CLI.

Image docker

With all this, she has more than once observed how other ladies easily make acquaintances, with the young people they liked, laugh and flirt. With the youngsters. And then they proudly defile with them under the arm.

"Hold on, everything will be fine, I'm near. " She flinches and quickly turns her head towards me. Without saying anything, she just smiles discreetly and turns her head to the board. I can feel a shiver go through her skin.

You will also like:

How did anyone reboot. - I asked, entering the game. Everything's Alright.

1803 1804 1805 1806 1807