Whenever a new repository is created, Titan will store metadata about the associated container image that is then stored with each commit and used to instantiate containers in the appropriate runtime context. The following information is taken from the original container image:
Whenever Titan creates a new container from a commit, Titan will attempt to use
the identical image that was used to create the commit. For images that have been
pushed to a registry, this is accomplished through the image digest, which ensures that
an exact match is used. There are cases where the digest doesn’t exist, such as
when using images built locally that have not been pushed to a registry, or
when the image came from a private registry that is no longer available. In these cases,
the image name and tag is used instead. For example, if the
is specified, Titan will prefer the digest of that image, as new images (corresponding to
Postgres minor releases) may be pushed under that tag. But in the event that
digest can’t be found, Titan will attempt to use whatever image corresponds to
postgres::11 at that point in time. Radically changing the image
configuration (most notably volume mappings) can have unintended consequences
and cause the repository to fail to be created.
There is currently no way to override the image attributes to change which image to use for a repository. This capability will be added in a future release.
Titan does not currently perform rigorous compatibility checks when pushing commits to a remote. It is possible to push radically different commits (different images, different volume mappings) that can cause significant issues when trying to switch between commits in a repository. Be careful that you are only pushing and pull compatible commits.
By default, Titan will forward any exposed ports on the container to the local
system. For example, running a PostgreSQL image will by default make the
container available at
localhost:5432. To disable this behavior, use the
-P option when cloning or running a repository. Custom port mappings can
be created using additional context-specific configuration options, described
Additional context-specific configuration can be specified when cloning or running a repository, but that configuration will not be persisted with the commits. For example, you can choose to forward ports differently (or not at all) on your workstation, run the containers on alternate docker networks, or use a different storage class for volumes in Kubernetes. This configuration may not translate across runtime environments (for example, a Docker network may not exist on a different system, or may not make sense at all in a Kubernetes environment), so you will have to specify it each time a repository is run or cloned. Once configured, this configuration will continue to be used for subsequent checkouts or commits.