[{"_1":2,"_171":-5,"_172":-5},"loaderData",{"_3":4,"_13":14,"_21":22,"_150":151},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","routes/_layout",{"_15":-5,"_16":17,"_18":17,"_19":11,"_20":11},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","showHoneypotTrap","routes/_layout.r.$namespace.$reponame",{"_23":24,"_25":-5,"_26":11,"_27":11,"_28":29,"_30":31,"_32":-5,"_33":11,"_34":35,"_84":85,"_103":104,"_143":-5,"_144":11,"_145":17,"_146":11,"_147":-5,"_148":149},"canonicalUrl","https://hub.docker.com/r/createdigitalspb/docker-baseimage/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","createdigitalspb","reponame","docker-baseimage","cloudBuildSource","isAutobuildsAvailable","repo",{"_36":37,"_38":39,"_41":42,"_43":44,"_45":11,"_46":47,"_48":49,"_50":51,"_53":31,"_28":29,"_54":55,"_56":-5,"_57":58,"_59":60,"_61":62,"_63":-5,"_64":58,"_65":66,"_67":11,"_68":29,"_69":70,"_75":17,"_76":77,"_81":29,"_82":83},"categories",[],"content_types",[40],"image","date_registered","2014-11-04T15:02:19.252161Z","description","","is_private","last_updated","2015-11-14T02:47:18.510569Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[52],"application/vnd.docker.distribution.manifest.v1+prettyjws","name","pull_count",1498,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","# A minimal Ubuntu base image modified for Docker-friendliness\n\nBaseimage-docker is a special [Docker](http://www.docker.io) image that is configured for correct use within Docker containers. It is Ubuntu, plus:\n\n * Modifications for Docker-friendliness.\n * Workarounds for [some Docker bugs](#workaroud_modifying_etc_hosts).\n * Useful administration tools.\n\nYou can use it as a base for your own Docker images.\n\nBaseimage-docker is available for pulling from [the Docker registry](https://index.docker.io/u/phusion/baseimage/)!\n\n### What are the problems with the stock Ubuntu base image?\n\nUbuntu is not designed to be run inside Docker. Its init system, Upstart, assumes that it's running on either real hardware or virtualized hardware, but not inside a Docker container. But inside a container you don't want a full system anyway, you want a minimal system. But configuring that minimal system for use within a container has many strange corner cases that are hard to get right if you are not intimately familiar with the Unix system model. This can cause a lot of strange problems.\n\nBaseimage-docker gets everything right. The \"Contents\" section describes all the things that it modifies.\n\n\n### Why use baseimage-docker?\n\nYou can configure the stock `ubuntu` image yourself from your Dockerfile, so why bother using baseimage-docker?\n\n * Configuring the base system for Docker-friendliness is no easy task. As stated before, there are many corner cases. By the time that you've gotten all that right, you've reinvented baseimage-docker. Using baseimage-docker will save you from this effort.\n * It reduces the time needed to write a correct Dockerfile. You won't have to worry about the base system and can focus on your stack and your app.\n * It reduces the time needed to run `docker build`, allowing you to iterate your Dockerfile more quickly.\n * It reduces download time during redeploys. Docker only needs to download the base image once: during the first deploy. On every subsequent deploys, only the changes you make on top of the base image are downloaded.\n\n-----------------------------------------\n\n**Related resources**:\n [Website](http://phusion.github.io/baseimage-docker/) |\n [Github](https://github.com/phusion/baseimage-docker) |\n [Docker registry](https://index.docker.io/u/phusion/baseimage/) |\n [Discussion forum](https://groups.google.com/d/forum/passenger-docker) |\n [Twitter](https://twitter.com/phusion_nl) |\n [Blog](http://blog.phusion.nl/)\n\n**Table of contents**\n\n * [What's inside the image?](#whats_inside)\n * [Overview](#whats_inside_overview)\n * [Wait, I thought Docker is about running a single process in a container?](#docker_single_process)\n * [Inspecting baseimage-docker](#inspecting)\n * [Using baseimage-docker as base image](#using)\n * [Getting started](#getting_started)\n * [Adding additional daemons](#adding_additional_daemons)\n * [Running scripts during container startup](#running_startup_scripts)\n * [Environment variables](#environment_variables)\n * [Centrally defining your own environment variables](#envvar_central_definition)\n * [Environment variable dumps](#envvar_dumps)\n * [Modifying environment variables](#modifying_envvars)\n * [Security](#envvar_security)\n * [Working around Docker's inability to modify /etc/hosts](#workaroud_modifying_etc_hosts)\n * [Disabling SSH](#disabling_ssh)\n * [Container administration](#container_administration)\n * [Running a one-shot command in a new container](#oneshot)\n * [Running a command in an existing, running container](#run_inside_existing_container)\n * [Login to the container via nsenter](#login_nsenter)\n * [Usage](#nsenter_usage)\n * [The `docker-bash` tool](#docker_bash)\n * [Login to the container via SSH](#login_ssh)\n * [Using the insecure key for one container only](#using_the_insecure_key_for_one_container_only)\n * [Enabling the insecure key permanently](#enabling_the_insecure_key_permanently)\n * [Using your own key](#using_your_own_key)\n * [The `docker-ssh` tool](#docker_ssh)\n * [Building the image yourself](#building)\n * [Conclusion](#conclusion)\n\n-----------------------------------------\n\n\n## What's inside the image?\n\n\n### Overview\n\n*Looking for a more complete base image, one that is ideal for Ruby, Python, Node.js and Meteor web apps? Take a look at [passenger-docker](https://github.com/phusion/passenger-docker).*\n\n| Component | Why is it included? / Remarks |\n| ---------------- | ------------------- |\n| Ubuntu 14.04 LTS | The base system. |\n| A **correct** init process | According to the Unix process model, [the init process](https://en.wikipedia.org/wiki/Init) -- PID 1 -- inherits all [orphaned child processes](https://en.wikipedia.org/wiki/Orphan_process) and must [reap them](https://en.wikipedia.org/wiki/Wait_(system_call)). Most Docker containers do not have an init process that does this correctly, and as a result their containers become filled with [zombie processes](https://en.wikipedia.org/wiki/Zombie_process) over time.

Furthermore, `docker stop` sends SIGTERM to the init process, which is then supposed to stop all services. Unfortunately most init systems don't do this correctly within Docker since they're built for hardware shutdowns instead. This causes processes to be hard killed with SIGKILL, which doesn't give them a chance to correctly deinitialize things. This can cause file corruption.

Baseimage-docker comes with an init process `/sbin/my_init` that performs both of these tasks correctly. |\n| Fixes APT incompatibilities with Docker | See https://github.com/dotcloud/docker/issues/1024. |\n| Workarounds for Docker bugs | [Learn more.](#workaroud_modifying_etc_hosts) |\n| syslog-ng | A syslog daemon is necessary so that many services - including the kernel itself - can correctly log to /var/log/syslog. If no syslog daemon is running, a lot of important messages are silently swallowed.

Only listens locally. |\n| logrotate | Rotates and compresses logs on a regular basis. |\n| SSH server | Allows you to easily login to your container to [inspect or administer](#login_ssh) things.

_SSH is only one of the methods provided by baseimage-docker for this purpose. The other method is through [the nsenter tool](#login_nsenter). SSH is also provided as an option because nsenter has many issues._

Password and challenge-response authentication are disabled by default. Only key authentication is allowed.

SSH access can be easily disabled if you so wish. Read on for instructions. |\n| cron | The cron daemon must be running for cron jobs to work. |\n| [runit](http://smarden.org/runit/) | Replaces Ubuntu's Upstart. Used for service supervision and management. Much easier to use than SysV init and supports restarting daemons when they crash. Much easier to use and more lightweight than Upstart. |\n| `setuser` | A tool for running a command as another user. Easier to use than `su`, has a smaller attack vector than `sudo`, and unlike `chpst` this tool sets `$HOME` correctly. Available as `/sbin/setuser`. |\n\nBaseimage-docker is very lightweight: it only consumes 6 MB of memory.\n\n\n### Wait, I thought Docker is about running a single process in a container?\n\nAbsolutely not true. Docker runs fine with multiple processes in a container. In fact, there is no technical reason why you should limit yourself to one process - it only makes things harder for you and breaks all kinds of essential system functionality, e.g. syslog.\n\nBaseimage-docker *encourages* multiple processes through the use of runit.\n\n\n## Inspecting baseimage-docker\n\nTo look around in the image, run:\n\n docker run --rm -t -i phusion/baseimage: /sbin/my_init -- bash -l\n\nwhere `` is [one of the baseimage-docker version numbers](https://github.com/phusion/baseimage-docker/blob/master/Changelog.md).\n\nYou don't have to download anything manually. The above command will automatically pull the baseimage-docker image from the Docker registry.\n\n\n## Using baseimage-docker as base image\n\n\n### Getting started\n\nThe image is called `phusion/baseimage`, and is available on the Docker registry.\n\n # Use phusion/baseimage as base image. To make your builds reproducible, make\n # sure you lock down to a specific version, not to `latest`!\n # See https://github.com/phusion/baseimage-docker/blob/master/Changelog.md for\n # a list of version numbers.\n FROM phusion/baseimage:\n \n # Set correct environment variables.\n ENV HOME /root\n \n # Regenerate SSH host keys. baseimage-docker does not contain any, so you\n # have to do that yourself. You may also comment out this instruction; the\n # init system will auto-generate one during boot.\n RUN /etc/my_init.d/00_regen_ssh_host_keys.sh\n \n # Use baseimage-docker's init system.\n CMD [\"/sbin/my_init\"]\n \n # ...put your own build instructions here...\n \n # Clean up APT when done.\n RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*\n\n\n### Adding additional daemons\n\nYou can add additional daemons (e.g. your own app) to the image by creating runit entries. You only have to write a small shell script which runs your daemon, and runit will keep it up and running for you, restarting it when it crashes, etc.\n\nThe shell script must be called `run`, must be executable, and is to be placed in the directory `/etc/service/`.\n\nHere's an example showing you how a memcached server runit entry can be made.\n\n ### In memcached.sh (make sure this file is chmod +x):\n #!/bin/sh\n # `/sbin/setuser memcache` runs the given command as the user `memcache`.\n # If you omit that part, the command will be run as root.\n exec /sbin/setuser memcache /usr/bin/memcached >>/var/log/memcached.log 2>&1\n\n ### In Dockerfile:\n RUN mkdir /etc/service/memcached\n ADD memcached.sh /etc/service/memcached/run\n\nNote that the shell script must run the daemon **without letting it daemonize/fork it**. Usually, daemons provide a command line flag or a config file option for that.\n\n\n### Running scripts during container startup\n\nThe baseimage-docker init system, `/sbin/my_init`, runs the following scripts during startup, in the following order:\n\n * All executable scripts in `/etc/my_init.d`, if this directory exists. The scripts are run in lexicographic order.\n * The script `/etc/rc.local`, if this file exists.\n\nAll scripts must exit correctly, e.g. with exit code 0. If any script exits with a non-zero exit code, the booting will fail.\n\nThe following example shows how you can add a startup script. This script simply logs the time of boot to the file /tmp/boottime.txt.\n\n ### In logtime.sh (make sure this file is chmod +x):\n #!/bin/sh\n date > /tmp/boottime.txt\n\n ### In Dockerfile:\n RUN mkdir -p /etc/my_init.d\n ADD logtime.sh /etc/my_init.d/logtime.sh\n\n\n### Environment variables\n\nIf you use `/sbin/my_init` as the main container command, then any environment variables set with `docker run --env` or with the `ENV` command in the Dockerfile, will be picked up by `my_init`. These variables will also be passed to all child processes, including `/etc/my_init.d` startup scripts, Runit and Runit-managed services. There are however a few caveats you should be aware of:\n\n * Environment variables on Unix are inherited on a per-process basis. This means that it is generally not possible for a child process to change the environment variables of other processes.\n * Because of the aforementioned point, there is no good central place for defining environment variables for all applications and services. Debian has the `/etc/environment` file but it only works in some situations.\n * Some services change environment variables for child processes. Nginx is one such example: it removes all environment variables unless you explicitly instruct it to retain them through the `env` configuration option. If you host any applications on Nginx (e.g. using the [passenger-docker](https://github.com/phusion/passenger-docker) image, or using Phusion Passenger in your own image) then they will not see the environment variables that were originally passed by Docker.\n\n`my_init` provides a solution for all these caveats.\n\n\n#### Centrally defining your own environment variables\n\nDuring startup, before running any [startup scripts](#running_startup_scripts), `my_init` imports environment variables from the directory `/etc/container_environment`. This directory contains files who are named after the environment variable names. The file contents contain the environment variable values. This directory is therefore a good place to centrally define your own environment variables, which will be inherited by all startup scripts and Runit services.\n\nFor example, here's how you can define an environment variable from your Dockerfile:\n\n RUN echo Apachai Hopachai > /etc/container_environment/MY_NAME\n\nYou can verify that it works, as follows:\n\n $ docker run -t -i /sbin/my_init -- bash -l\n ...\n *** Running bash -l...\n # echo $MY_NAME\n Apachai Hopachai\n\n**Handling newlines**\n\nIf you've looked carefully, you'll notice that the 'echo' command actually prints a newline. Why does $MY_NAME not contain a newline then? It's because `my_init` strips the trailing newline, if any. If you intended on the value having a newline, you should add *another* newline, like this:\n\n RUN echo -e \"Apachai Hopachai\\n\" > /etc/container_environment/MY_NAME\n\n\n#### Environment variable dumps\n\nWhile the previously mentioned mechanism is good for centrally defining environment variables, it by itself does not prevent services (e.g. Nginx) from changing and resetting environment variables from child processes. However, the `my_init` mechanism does make it easy for you to query what the original environment variables are.\n\nDuring startup, right after importing environment variables from `/etc/container_environment`, `my_init` will dump all its environment variables (that is, all variables imported from `container_environment`, as well as all variables it picked up from `docker run --env`) to the following locations, in the following formats:\n\n * `/etc/container_environment`\n * `/etc/container_environment.sh` - a dump of the environment variables in Bash format. You can source the file directly from a Bash shell script.\n * `/etc/container_environment.json` - a dump of the environment variables in JSON format.\n\nThe multiple formats makes it easy for you to query the original environment variables no matter which language your scripts/apps are written in.\n\nHere is an example shell session showing you how the dumps look like:\n\n $ docker run -t -i \\\n --env FOO=bar --env HELLO='my beautiful world' \\\n phusion/baseimage: /sbin/my_init -- \\\n bash -l\n ...\n *** Running bash -l...\n # ls /etc/container_environment\n FOO HELLO HOME HOSTNAME PATH TERM container\n # cat /etc/container_environment/HELLO; echo\n my beautiful world\n # cat /etc/container_environment.json; echo\n {\"TERM\": \"xterm\", \"container\": \"lxc\", \"HOSTNAME\": \"f45449f06950\", \"HOME\": \"/root\", \"PATH\": \"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin\", \"FOO\": \"bar\", \"HELLO\": \"my beautiful world\"}\n # source /etc/container_environment.sh\n # echo $HELLO\n my beautiful world\n\n\n#### Modifying environment variables\n\nIt is even possible to modify the environment variables in `my_init` (and therefore the environment variables in all child processes that are spawned after that point in time), by altering the files in `/etc/container_environment`. After each time `my_init` runs a [startup script](#running_startup_scripts), it resets its own environment variables to the state in `/etc/container_environment`, and re-dumps the new environment variables to `container_environment.sh` and `container_environment.json`.\n\nBut note that:\n\n * modifying `container_environment.sh` and `container_environment.json` has no effect.\n * Runit services cannot modify the environment like that. `my_init` only activates changes in `/etc/container_environment` when running startup scripts.\n\n\n#### Security\n\nBecause environment variables can potentially contain sensitive information, `/etc/container_environment` and its Bash and JSON dumps are by default owned by root, and accessible only by the `docker_env` group (so that any user added this group will have these variables automatically loaded).\n\nIf you are sure that your environment variables don't contain sensitive data, then you can also relax the permissions on that directory and those files by making them world-readable:\n\n RUN chmod 755 /etc/container_environment\n RUN chmod 644 /etc/container_environment.sh /etc/container_environment.json\n\n\n### Working around Docker's inability to modify /etc/hosts\n\nIt is currently not possible to modify /etc/hosts inside a Docker container because of [Docker bug 2267](https://github.com/dotcloud/docker/issues/2267). Baseimage-docker includes a workaround for this. You have to be explicitly opt-in for the workaround.\n\nThe workaround involves modifying a system library, libnss_files.so.2, so that it looks for the host file in /etc/workaround-docker-2267/hosts instead of /etc/hosts. Instead of modifying /etc/hosts, you modify /etc/workaround-docker-2267/hosts instead.\n\nAdd this to your Dockerfile to opt-in for the workaround. This command modifies libnss_files.so.2 as described above.\n\n RUN /usr/bin/workaround-docker-2267\n\n(You don't necessarily have to run this command from the Dockerfile. You can also run it from a shell inside the container.)\n\nTo verify that it works, [open a bash shell in your container](#inspecting), modify /etc/workaround-docker-2267/hosts, and check whether it had any effect:\n\n bash# echo 127.0.0.1 my-test-domain.com >> /etc/workaround-docker-2267/hosts\n bash# ping my-test-domain.com\n ...should ping 127.0.0.1...\n\n**Note on apt-get upgrading:** if any Ubuntu updates overwrite libnss_files.so.2, then the workaround is removed. You have to re-enable it by running `/usr/bin/workaround-docker-2267`. To be safe, you should run this command every time after running `apt-get upgrade`.\n\n\n### Disabling SSH\n\nBaseimage-docker enables an SSH server by default, so that you can [use SSH](#login_ssh) to [administer your container](#container_administration). In case you do not want to enable SSH, here's how you can disable it:\n\n RUN rm -rf /etc/service/sshd /etc/my_init.d/00_regen_ssh_host_keys.sh\n\n\n## Container administration\n\nOne of the ideas behind Docker is that containers should be stateless, easily restartable, and behave like a black box. However, you may occasionally encounter situations where you want to login to a container, or to run a command inside a container, for development, inspection and debugging purposes. This section describes how you can administer the container for those purposes.\n\n\n### Running a one-shot command in a new container\n\n_**Note:** This section describes how to run a command insider a -new- container. To run a command inside an existing running container, see [Running a command in an existing, running container](#run_inside_existing_container)._\n\nNormally, when you want to create a new container in order to run a single command inside it, and immediately exit after the command exits, you invoke Docker like this:\n\n docker run YOUR_IMAGE COMMAND ARGUMENTS...\n\nHowever the downside of this approach is that the init system is not started. That is, while invoking `COMMAND`, important daemons such as cron and syslog are not running. Also, orphaned child processes are not properly reaped, because `COMMAND` is PID 1.\n\nBaseimage-docker provides a facility to run a single one-shot command, while solving all of the aforementioned problems. Run a single command in the following manner:\n\n docker run YOUR_IMAGE /sbin/my_init -- COMMAND ARGUMENTS ...\n\nThis will perform the following:\n\n * Runs all system startup files, such as /etc/my_init.d/* and /etc/rc.local.\n * Starts all runit services.\n * Runs the specified command.\n * When the specified command exits, stops all runit services.\n\nFor example:\n\n $ docker run phusion/baseimage: /sbin/my_init -- ls\n *** Running /etc/my_init.d/00_regen_ssh_host_keys.sh...\n No SSH host key available. Generating one...\n Creating SSH2 RSA key; this may take some time ...\n Creating SSH2 DSA key; this may take some time ...\n Creating SSH2 ECDSA key; this may take some time ...\n *** Running /etc/rc.local...\n *** Booting runit daemon...\n *** Runit started as PID 80\n *** Running ls...\n bin boot dev etc home image lib lib64 media mnt opt proc root run sbin selinux srv sys tmp usr var\n *** ls exited with exit code 0.\n *** Shutting down runit daemon (PID 80)...\n *** Killing all processes...\n\nYou may find that the default invocation is too noisy. Or perhaps you don't want to run the startup files. You can customize all this by passing arguments to `my_init`. Invoke `docker run YOUR_IMAGE /sbin/my_init --help` for more information.\n\nThe following example runs `ls` without running the startup files and with less messages, while running all runit services:\n\n $ docker run phusion/baseimage: /sbin/my_init --skip-startup-files --quiet -- ls\n bin boot dev etc home image lib lib64 media mnt opt proc root run sbin selinux srv sys tmp usr var\n\n\n### Running a command in an existing, running container\n\nThere are two ways to run a command inside an existing, running container.\n\n * Through the `nsenter` tool. This tool uses Linux kernel system calls in order to execute a command within the context of a container. Learn more in [Login to the container, or running a command inside it, via nsenter](#login_nsenter).\n * Through SSH. This approach requires running an SSH daemon inside the container, and requires you to setup SSH keys. Learn more in [Login to the container, or running a command inside it, via SSH](#login_ssh).\n\nBoth way have their own pros and cons, which you can learn in their respective subsections.\n\n\n### Login to the container, or running a command inside it, via nsenter\n\nYou can use the `nsenter` tool on the Docker host OS to login to any container that is based on baseimage-docker. You can also use it to run a command inside a running container. `nsenter` works by using Linux kernel system calls.\n\nHere's how it compares to [using SSH to login to the container or to run a command inside it](#login_ssh):\n\n * Pros\n * Does not require running an SSH daemon inside the container.\n * Does not require setting up SSH keys.\n * Works on any container, even containers not based on baseimage-docker.\n * Cons\n * Processes executed by `nsenter` behave in a slightly different manner than normal. For example, they cannot be killed by any normal processes inside the container. This applies to all child processes as well.\n * If the `nsenter` process is terminated by a signal (e.g. with the `kill` command), then the command that is executed by nsenter is *not* killed and cleaned up. You will have to do that manually. (Note that terminal control commands like Ctrl-C *do* clean up all child processes, because terminal signals are sent to all processes in the terminal session.)\n * Requires learning another tool.\n * Requires root privileges on the Docker host.\n * Requires the `nsenter` tool to be available on the Docker host. At the time of writing (July 2014), most Linux distributions do not ship it. However, baseimage-docker provides a precompiled binary, and allows you to easily use it, through its [docker-bash](#docker_bash) tool.\n * Not possible to allow users to login to the container without also letting them login to the Docker host.\n\n\n#### Usage\n\nFirst, ensure that `nsenter` is installed. At the time of writing (July 2014), almost no Linux distribution ships the `nsenter` tool. However, we provide [a precompiled binary](#docker_bash) that anybody can use.\n\nAnyway, start a container:\n\n docker run YOUR_IMAGE\n\nFind out the ID of the container that you just ran:\n\n docker ps\n\nOnce you have the ID, look for the PID of the main process inside the container.\n\n docker inspect -f \"{{ .State.Pid }}\" \n\nNow that you have the cont","has_starred","hub_user","immutable_tags_settings",{"_71":11,"_72":73},"enabled","rules",[74],".*","is_automated","permissions",{"_78":17,"_79":11,"_80":11},"read","write","admin","user","storage_size",234696077,"orgData",{"_86":87,"_88":89,"_90":91,"_92":29,"_93":44,"_94":44,"_95":44,"_96":44,"_97":98,"_99":44,"_100":44,"_101":44,"_102":17},"id","220d547474c111e4bea40242ac11001b","uuid","220d5474-74c1-11e4-bea4-0242ac11001b","type","organization","orgname","full_name","location","company","profile_url","date_joined","2014-10-31T12:57:59.369147Z","gravatar_url","gravatar_email","badge","is_active","recentTags",[105],{"_106":40,"_107":108,"_109":110,"_111":112,"_86":113,"_114":115,"_46":130,"_131":132,"_133":134,"_135":52,"_53":136,"_137":138,"_139":121,"_140":130,"_141":62,"_142":17},"content_type","creator",133182,"digest","sha256:dfd5d5adc9a803e61270a770b93e3c94850e5b75b852d63c6461640c23ac661a","full_size",234649092,104025,"images",[116],{"_117":118,"_109":110,"_119":44,"_120":121,"_122":123,"_124":44,"_125":44,"_126":-5,"_127":128,"_59":62,"_129":-5},"architecture","amd64","features","last_pulled","2026-09-10T07:04:40.174835188Z","last_pushed","2015-11-14T02:47:18Z","os","os_features","os_version","size",234650162,"variant","2015-11-14T02:47:22.826796Z","last_updater",265837,"last_updater_username","createdigitalspbmain","media_type","latest","repository",76838,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"routes/_layout.r.$namespace.$reponame.tags",{"_34":152,"_159":160,"_148":169,"_170":11},{"_36":153,"_38":154,"_41":42,"_43":44,"_45":11,"_46":47,"_48":49,"_50":155,"_53":31,"_28":29,"_54":55,"_56":-5,"_57":58,"_59":60,"_61":62,"_63":-5,"_64":58,"_65":66,"_67":11,"_68":29,"_69":156,"_75":17,"_76":158,"_81":29,"_82":83},[],[40],[52],{"_71":11,"_72":157},[74],{"_78":17,"_79":11,"_80":11},"tags",{"_161":60,"_162":-5,"_163":-5,"_164":165},"count","next","previous","results",[166],{"_106":40,"_107":108,"_109":110,"_111":112,"_86":113,"_114":167,"_46":130,"_131":132,"_133":134,"_135":52,"_53":136,"_137":138,"_139":121,"_140":130,"_141":62,"_142":17},[168],{"_117":118,"_109":110,"_119":44,"_120":121,"_122":123,"_124":44,"_125":44,"_126":-5,"_127":128,"_59":62,"_129":-5},[],"canDeleteTags","actionData","errors"]

createdigitalspb/docker-baseimage

Tags for createdigitalspb/docker-baseimage