[{"_1":2,"_161":-5,"_162":-5},"loaderData",{"_3":4,"_17":18,"_25":26,"_140":141},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7,"_13":14,"_15":16},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","theme","system","contrast","normal","routes/_layout",{"_19":-5,"_20":21,"_22":21,"_23":11,"_24":21},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","showHoneypotTrap","routes/_layout.r.$namespace.$reponame",{"_27":28,"_29":-5,"_30":11,"_31":11,"_32":33,"_34":35,"_36":-5,"_37":11,"_38":39,"_88":-5,"_89":90,"_129":-5,"_130":11,"_131":21,"_132":11,"_133":-5,"_134":11,"_135":-5,"_136":137,"_138":91,"_139":-7},"canonicalUrl","https://hub.docker.com/r/cloudhotspot/sample-django-app-dev/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","cloudhotspot","reponame","sample-django-app-dev","cloudBuildSource","isAutobuildsAvailable","repo",{"_40":41,"_42":43,"_45":46,"_47":48,"_49":11,"_50":51,"_52":53,"_54":55,"_57":35,"_32":33,"_58":59,"_60":44,"_61":62,"_63":64,"_65":66,"_67":-5,"_68":62,"_69":70,"_71":11,"_72":33,"_73":74,"_79":21,"_80":81,"_85":33,"_86":87},"categories",[],"content_types",[44],"image","date_registered","2015-11-04T11:45:55.361945Z","description","Sample Django Application Dev Image\n","is_private","last_updated","2018-04-12T18:32:56.287322Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[56],"application/vnd.docker.container.image.v1+json","name","pull_count",1108,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","# Python Packager\n\nA methodology for continuous integration and packaging of Python and Django applications using Python Wheels and Docker. \n\nFull documentation is provided at read the docs. \n\nThe goals of this methodology include:\n\n- Portable workflow - you should be able to run this workflow locally on a developer machine or on a CI system like Jenkins.\n- Create a Python virtual environment (even inside containers, see why here).\n- Create deployable **native** application artefacts (i.e. Python Wheels, not archives or operating system packages).\n- Create deployable runtime environment artefacts (i.e. Docker images). \n- Create simple to maintain manifests that describe application and runtime environment dependencies.\n- Eliminate development and test dependencies from production runtime environment artefacts.\n- Fast developer feedback - accelerate testing and build activities through Python Wheels caching.\n- Ease of use - reduce complexity of running long Docker commands and orchestrating workflows to simple `make` style commands.\n- Reusability - use Docker image layering to build dependency and configuration trees that promote reusability\n- Leverage familiar Python tooling - use of `pip` and `virtualenv` makes it possible to extract this workflow outside of Docker\n\n## Workflow\n\nThe initial setup to get started is as follows:\n\n- Prepare your application\n- Configure your environment\n- Create base image\n- Create development image\n- Create helper images (optional)\n\nWith the above in place, the CI workflow can take place. The CI workflow is triggered on each source code commit and thus benefits the most from automation and performance optimisations.\n\nThe CI workflow (assuming all tests pass) is as follows:\n\n- Commit to source code repository \n- Create test environment and run unit/integration tests\n- Build application artefacts (i.e. Python wheels)\n- Build runtime environment artefacts (i.e. Docker images)\n- Deploy release environment for the full application stack (e.g. including databases, caches)\n- Run functional tests against release environment\n- Publish application and runtime environment artefacts \n\nThis project demonstrates the workflow outlined above, providing the ability to execute each step on any Linux/OS X machine running a Docker client with access to a Docker host. This workflow can also be automated within a CI system such as Jenkins, triggered by a commit to the source code repository for the application.\n\nThe rest of this document provides an example to enable you to get started, and assumes you are using the included sample application located in the `src` folder. For further information on how to prepare your application for this workflow, refer to the documentation.\n\n## Prerequisites\n\n- Linux/OS X computer\n- Docker client - version 1.8 or higher\n- Docker Compose - version 1.5 or higher\n- Docker daemon (either running locally, on local VM or on a remote host)\n- Docker daemon must have Internet connectivity\n- Docker Machine (Recommended) - if testing on locally OS X, Docker Machine along with your favourite virualisation software is recommended\n\n## Initial Setup\n\n### Makefile Environment Settings\n\nFirst, you need to configure your environment either by setting environment variables or by configuring the top portion of the `Makefile`:\n\n```bash \nREPO_NS ?= mycompany\nAPP_NAME ?= myapp\nREPO_VERSION ?= latest\nTEST_ENV_NAME ?= $(REPO_NS)$(APP_NAME)test\nRELEASE_ENV_NAME ?= $(REPO_NS)$(APP_NAME)release\n\n...\n...\n```\nThese settings will determine how the various Docker images and containers that created and used are named. In general, you only need to modify:\n\n- REPO_NS\n- APP_NAME\n\n### Docker Compose Environment Settings\n\nDocker Compose is used to define the following environments for this workflow:\n\n- Development/Test Environment - this is used for the unit/integration test and build phases\n- Release Environment - this is used for the functional test and release phases\n\nA set of docker compose files are including in the `docker` folder of this repository:\n\n- `base.yml` - defines services and settings common to both the test and release environments\n- `dev.yml` - defines services and settings for the development/test environment\n- `release.yml` - defines services and settings for the release environment\n\nThese files are specifically configured for the sample application and must be adapted for your application.\n\nFor further information on how to configure the Docker Compose environment settings, refer to the documentation.\n\n### Docker Images\n\nThe CI workfow requires the following images to be created or available for your CI workflow:\n\n- Base image\n- Development image\n\n> The order of building the above images is important and must be followed from top to bottom. \n\nIn addition to the above, the workflow introduces the concept of a **helper** image, which provides additional functionality specific to the sample application but may be useful for your own workflows.\n\n### Creating the Base Image\n\nCreate the base image using the `make image docker/base` command. \n\nThe base image should include any common dependencies/configuration settings to both development/test images and production images. \n\nThe base image includes an entrypoint script `entrypoint.sh` that activates the Python virtual environment and runs any command in the virtual environment. This entrypoint is inherited by all child images, promoting reusability.\n\n```bash\n$ make image docker/base\n=> Building Docker image mycompany/myapp-base:56ffcba...\nSending build context to Docker daemon 4.489 MB\nStep 0 : FROM ubuntu:trusty\n ---> a005e6b7dd01\nStep 1 : MAINTAINER Justin Menga \n ---> Running in 32f1743c9b29\n ---> 161672d57fb4\nRemoving intermediate container 32f1743c9b29\nStep 2 : RUN sed -i \"s/http:\\/\\/archive./http:\\/\\/nz.archive./g\" /etc/apt/sources.list && apt-get update && apt-get install -qyy -o APT::Install-Recommends=false -o APT::Install-Suggests=false python-virtualenv python libffi6 openssl libpython2.7 python-mysqldb\n ---> Running in 73b330b7ea01\n...\n...\nStep 3 : RUN virtualenv /appenv && . /appenv/bin/activate && pip install pip==7.1.2\n ---> Running in 8bb6b81eb600\nNew python executable in /appenv/bin/python\nInstalling setuptools, pip...done.\nDownloading/unpacking pip==7.1.2\nInstalling collected packages: pip\n Found existing installation: pip 1.5.4\n Uninstalling pip:\n Successfully uninstalled pip\nSuccessfully installed pip\nCleaning up...\n ---> 269c64f8032c\nRemoving intermediate container 8bb6b81eb600\nStep 4 : ADD scripts/entrypoint.sh /usr/local/bin/entrypoint.sh\n ---> 6f9432cbfbdd\nRemoving intermediate container 0ac482760d6e\nStep 5 : RUN chmod +x /usr/local/bin/entrypoint.sh\n ---> Running in b007759635ba\n ---> 8b22b92fc5a9\nRemoving intermediate container b007759635ba\nStep 6 : ENTRYPOINT entrypoint.sh\n ---> Running in c768ff3cf1d8\n ---> 0c5087e1533d\nRemoving intermediate container c768ff3cf1d8\nSuccessfully built 0c5087e1533d\n=> Removing dangling images...\n=> Image complete\nmake: `docker/base' is up to date.\n```\n\n### Creating the Development Image\n\nCreate the builder image using the `make image docker/builder` command. The development image should include all dependencies required for development, test and build purposes. This image adds the `test.sh` entrypoint script, which activates the virtual environment, installs the application and then runs a command string (by default `python manage.py test`):\n\n> You must ensure the `FROM` directive in `docker/builder/Dockerfile` references the correct base image and version (see Step 0 below):\n\n```bash\n$ make image docker/dev\nmake image docker/dev\n=> Building Docker image mycompany/myapp-dev:aa54358...\nSending build context to Docker daemon 4.671 MB\nStep 0 : FROM mycompany/myapp-base:latest\n ---> 189a212d6439\nStep 1 : MAINTAINER Justin Menga \n ---> Using cache\n ---> 3f492367a6f6\nStep 2 : RUN apt-get install -qy libffi-dev libssl-dev python-dev libmysqlclient-dev\n ---> Using cache\n ---> dab75995db76\nStep 3 : RUN . /appenv/bin/activate && pip install wheel\n ---> Using cache\n ---> ef510aa5f82a\nStep 4 : ENV WHEELHOUSE /wheelhouse PIP_WHEEL_DIR /wheelhouse PIP_FIND_LINKS /wheelhouse XDG_CACHE_HOME /cache\n ---> Using cache\n ---> a44a5ef2f28e\nStep 5 : VOLUME /wheelhouse\n ---> Using cache\n ---> 1a7c3a24ac7a\nStep 6 : VOLUME /application\n ---> Using cache\n ---> 0a06eb715731\nStep 7 : WORKDIR /application\n ---> Using cache\n ---> 459a81d2b166\nStep 8 : ADD scripts/test.sh /usr/local/bin/test.sh\n ---> Using cache\n ---> 0e96be69b6b3\nStep 9 : RUN chmod +x /usr/local/bin/test.sh\n ---> Using cache\n ---> 9ececed81875\nStep 10 : ENTRYPOINT test.sh\n ---> Running in 19ce60284ec2\n ---> 69dd96b1b581\nRemoving intermediate container 19ce60284ec2\nStep 11 : CMD python manage.py test\n ---> Running in 545a1f427287\n ---> f8b528d4dee5\nRemoving intermediate container 545a1f427287\nSuccessfully built f8b528d4dee5\n=> Tagging image as latest...\n=> Removing dangling images...\nDeleted: 40af76fef075247beef9fe513613e76575e4710db32fd2e5a6af713b0142773d\n=> Image complete\nmake: `docker/dev' is up to date.\n```\n\n### Creating the Helper Image (Optional)\n\nA helper image referred to as an *agent image* is included in this workflow but note that this is specific to the sample application. The agent image runs an Ansible playbook (defined in `ansible/agent/site.yml`) that is used to allow the MySQL database container time to properly start up when bringing up the environments used in the workflow. Of course you are free to take whatever approach you like to achieve this goal, this approach is just one of many possible solutions to this problem.\n\nYou can create the agent image using the `make image docker/agent` command. \n\nThis image has Ansible installed and `ansible-playbook` defined as its entrypoint. By supplying the agent container with a playbook file and appropriate command string referencing the file, this image provides an easy mechanism to invoke an arbitrary Ansible playbook within the test or release environments in this workflow.\n\n```bash\n$ make image docker/agent\n=> Building Docker image mycompany/myapp-agent:56ffcba...\nSending build context to Docker daemon 4.492 MB\nStep 0 : FROM ubuntu:trusty\n ---> a005e6b7dd01\nStep 1 : MAINTAINER Justin Menga \n ---> Using cache\n ---> 161672d57fb4\nStep 2 : RUN sed -i \"s/http:\\/\\/archive./http:\\/\\/nz.archive./g\" /etc/apt/sources.list && apt-get update -qy && apt-get install -qy software-properties-common && apt-add-repository -y ppa:ansible/ansible && apt-get update -qy && apt-get install -qy ansible\n ---> Running in 879fa3c9923f\n...\n...\nStep 3 : VOLUME /ansible\n ---> Running in 4548ca97e3b0\n ---> c5423b6ca790\nRemoving intermediate container 4548ca97e3b0\nStep 4 : WORKDIR /ansible\n ---> Running in 81ebf5b96c2f\n ---> 67e7dde7c4c5\nRemoving intermediate container 81ebf5b96c2f\nStep 5 : ENTRYPOINT ansible-playbook\n ---> Running in dfb2d85663ca\n ---> 68bb8a312b7b\nRemoving intermediate container dfb2d85663ca\nSuccessfully built 68bb8a312b7b\n=> Removing dangling images...\n=> Image complete\nmake: `docker/agent' is up to date.\n```\n\n## Continuous Integration Workflow\n\nWith the application, environment and base/builder/test images in place, the continuous integration workflow can be executed. This workflow would typically be invoked on each application source code commit in a production continuous integration system. \n\nHowever it is possible to complete the steps described below manually on a development machine as required.\n\n> The `make all` command provides a one-shot command to clean the environments, execute the workflow and then bootstrap and activate the release environment.\n\nOn each commit, the continuous integration workflow starts by running tests inside the test container using the `make test` command. \n\nThis will install the application and run `python manage.py test` in a container based upon the test image:\n\n> The Docker Compose environments include a volume container that stores the pip cache on the Docker host in `/tmp/`. This allows subsequent invocations of `make test` and `make build` to use cached dependencies for much faster execution times (see example below where the first run of `make test` takes 36 seconds, whilst the second run takes just under 9 seconds). \n\n```bash\n$ time make test\n=> Ensuring database is ready...\nCreating mycompanymyapptest_db_1...\n...\n...\n=> Running tests...\nCreating mycompanymyapptest_cache_1...\nProcessing /application\n...\n...\nCreating test database for alias 'default'...\n..........\n----------------------------------------------------------------------\nRan 10 tests in 0.066s\n\nOK\nDestroying test database for alias 'default'...\n=> Testing complete\n\nreal 0m36.645s\nuser 0m0.674s\nsys 0m0.201s\n\n$ time make test\n=> Ensuring database is ready...\n...\n=> Running tests...\nProcessing /application\nCollecting Django>=1.8.5 (from SampleDjangoApp==0.1)\n Using cached Django-1.8.5-py2.py3-none-any.whl\n...\n...\nCreating test database for alias 'default'...\n..........\n----------------------------------------------------------------------\nRan 10 tests in 0.044s\n\nOK\nDestroying test database for alias 'default'...\n\nreal 0m7.826s\nuser 0m0.476s\nsys 0m0.130s\n```\n\nAfter testing is successful, application artefacts are built using the `make build` command. This invokes a builder container defined in the `dev.yml` Docker Compose file:\n\n```yaml\n...\n...\nbuilder:\n image: mycompany/myapp-dev:latest\n volumes:\n - ../src:/application\n - ../target:/wheelhouse\n volumes_from:\n - cache\n entrypoint: \"entrypoint.sh\"\n command: [\"pip\", \"wheel\", \".\"]\n```\n\n> Notice how the builder container overrides the default entrypoint and command string for the development image. This illustrates the flexibility of Docker images.\n\nThe build process will output a Python Wheel for the application and each dependency in the `/wheelhouse` folder on the container, which is mapped to the `target` folder on the Docker host (this mapping can be changed in the Docker Compose environment settings):\n\n```bash\n$ make build\n=> Building Python wheels...\nProcessing /application\nCollecting Django>=1.8.5 (from SampleDjangoApp==0.1)\n Using cached Django-1.8.5-py2.py3-none-any.whl\n Saved /wheelhouse/Django-1.8.5-py2.py3-none-any.whl\nCollecting uwsgi>=2.0 (from SampleDjangoApp==0.1)\n Saved /wheelhouse/uWSGI-2.0.11.2-py2-none-any.whl\nCollecting mysql-python (from SampleDjangoApp==0.1)\n Saved /wheelhouse/MySQL_python-1.2.5-cp27-none-linux_x86_64.whl\nSkipping Django, due to already being wheel.\nSkipping uwsgi, due to already being wheel.\nSkipping mysql-python, due to already being wheel.\nBuilding wheels for collected packages: SampleDjangoApp\n Running setup.py bdist_wheel for SampleDjangoApp\n Stored in directory: /wheelhouse\nSuccessfully built SampleDjangoApp\n=> Build complete\n```\n\nWith application artefacts built, the final step is to create a release image using the `make release` command. \n\nThis will create an image based from the base image, ensuring development and test dependencies are not included in production releases. The release image is tagged with the current Git commit short SHA hash and also tagged with the value of the REPO_VERSION environment variable (set to latest by default). \n\n```bash\n$ make release\n=> Building Docker image mycompany/myapp-release:56ffcba...\nSending build context to Docker daemon 15.33 MB\nStep 0 : FROM mycompany/myapp-base\n ---> 56380f292315\nStep 1 : MAINTAINER Justin Menga \n ---> Using cache\n ---> 8f3898ac6d14\nStep 2 : ENV PORT 8000 PROJECT_NAME SampleDjangoApp\n ---> Using cache\n ---> 55a5b15e6955\nStep 3 : ADD target /wheelhouse\n ---> Using cache\n ---> b2860b70ef41\nStep 4 : RUN . /appenv/bin/activate && pip install --no-index -f wheelhouse ${PROJECT_NAME} && rm -rf /wheelhouse\n ---> Using cache\n ---> d5f51f7a5be5\nStep 5 : EXPOSE ${PORT}\n ---> Using cache\n ---> 424d2ba7bb37\nSuccessfully built 424d2ba7bb37\n=> Tagging image as latest...\n=> Removing dangling images...\n=> Image complete\nmake[1]: `docker/release' is up to date.\n```\n\n### Running the Release Environment\n\nWith release application artefacts and runtime images built, at this point it is possible to establish a sandbox environment with the application release using tools like docker-compose. With the sandbox environment in place, automated functional/integration tests can be executed as a final gate before publishing the release application artefact and runtime image. With the various artefacts published, your continuous deployment processes can be triggered to release the application into the appropriate target environments.\n\nThis project includes a `make bootstrap` command that performs the following tasks specific to the sample application:\n\n- Bring up release environment database and ensure it is ready\n- Runs Django migrations\n- Creates Django admin super user\n- Collects Django static files\n\nWith the release environment bootstrapped, you can run `make start` which will start the release environment in a ready to run state. Similarly you can use `make stop` to stop the release environment without destroying it.\n\nYou can also run arbitrary commands against the created release image, which can be useful. The following commands can be used for this:\n\n- `make run ` - creates a container from the release image, runs an arbitrary command and destroys the container\n- `make manage ` - creates a container from the release image, runs a Django admin command and destroys the container\n\nExamples:\n\n```bash\n$ make bootstrap\n=> Bootstraping release environment...\n=> Ensuring database is ready...\nCreating mycompanymyapprelease_db_1...\n...\n...\nTASK: [Message] ***************************************************************\nok: [localhost] => {\n \"msg\": \"Probing db:3306 with delay=0s and timeout=180s\"\n}\n\nTASK: [Waiting for host to respond...] ****************************************\nok: [localhost -> 127.0.0.1]\n...\n...\n=> Running migrations...\n=> Running python manage.py migrate...\nCreating mycompanymyapprelease_static_1...\nOperations to perform:\n Synchronize unmigrated apps: staticfiles, messages\n Apply all migrations: admin, contenttypes, polls, auth, sessions\nSynchronizing apps without migrations:\n Creating tables...\n Running deferred SQL...\n Installing custom SQL...\nRunning migrations:\n Rendering model states... DONE\n Applying contenttypes.0001_initial... OK\n Applying auth.0001_initial... OK\n Applying admin.0001_initial... OK\n Applying contenttypes.0002_remove_content_type_name... OK\n Applying auth.0002_alter_permission_name_max_length... OK\n Applying auth.0003_alter_user_email_max_length... OK\n Applying auth.0004_alter_user_username_opts... OK\n Applying auth.0005_alter_user_last_login_null... OK\n Applying auth.0006_require_contenttypes_0002... OK\n Applying polls.0001_initial... OK\n Applying sessions.0001_initial... OK\n=> Creating Django admin user...\n=> Running python manage.py createsuperuser...\nUsername (leave blank to use 'root'): admin\nEmail address: admin@example.com\nPassword: ********\nPassword (again): ********\nSuperuser created successfully.\n=> Collecting static assets...\n=> Running python manage.py collectstatic --noinput...\nCopying '/appenv/local/lib/python2.7/site-packages/django/contrib/admin/static/admin/js/urlify.js'\nCopying '/appenv/local/lib/python2.7/site-packages/django/contrib/admin/static/admin/js/SelectBox.js'\n...\n...\n\n63 static files copied to '/var/www/mysite/static'.\n=> Bootstrap complete\n\n$ make start\n=> Starting release environment...\nmycompanymyapprelease_db_1 is up-to-date\nStarting mycompanymyapprelease_static_1...\nCreating mycompanymyapprelease_app_1...\nCreating mycompanymyapprelease_agent_1...\n=> Release environment started\n```\n\n```bash\n# Get an interactive prompt\n$ make run bash\ndocker run -it --rm -p 8000:8000 mycompany/myapp:latest bash\nroot@a584b6cb23a6:/# manage.py check\nSystem check identified no issues (0 silenced).\nroot@a584b6cb23a6:/# ping 8.8.8.8\nPING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.\n64 bytes from 8.8.8.8: icmp_seq=1 ttl=127 time=39.0 ms\n```\n\n```bash\n# Run Django migrations\n$ make manage migrate\ndocker run -it --rm -p 8000:8000 mycompany/myapp:latest manage.py migrate\nOperations to perform:\n Synchronize unmigrated apps: staticfiles, messages\n Apply all migrations: admin, contenttypes, polls, auth, sessions\nSynchronizing apps without migrations:\n Creating tables...\n Running deferred SQL...\n Installing custom SQL...\nRunning migrations:\n Rendering model states... DONE\n Applying contenttypes.0001_initial... OK\n Applying auth.0001_initial... OK\n Applying admin.0001_initial... OK\n Applying contenttypes.0002_remove_content_type_name... OK\n Applying auth.0002_alter_permission_name_max_length... OK\n Applying auth.0003_alter_user_email_max_length... OK\n Applying auth.0004_alter_user_username_opts... OK\n Applying auth.0005_alter_user_last_login_null... OK\n Applying auth.0006_require_contenttypes_0002... OK\n Applying polls.0001_initial... OK\n Applying sessions.0001_initial... OK\n```\n\n```bash\n# Run Django collectstatic\n$ make -- manage collectstatic --noinput\ndocker run -it --rm -p 8000:8000 mycompany/myapp:latest manage.py collectstatic --noinput\nCopying '/appenv/local/lib/python2.7/site-packages/django/contrib/admin/static/admin/css/base.css'\nCopying '/appenv/local/lib/python2.7/site-packages/django/contrib/admin/static/admin/css/rtl.css'\n...\n63 static files copied to '/var/www/mysite/static'.\n```\n\n> Use the `--` separator after the `make` command to allow any subsequent arguments to be passed to the `docker run` command, rather than being interpreted by the `make` command as arguments.\n\n> Currently there are some limitations related to how make works that restrict colons and possibly other special characters being used in the command string passed to `make run` and `make manage`.\n\n## TODO\n\n- Add automatic versioning\n- Add support to publish Python Wheels and Docker Images\n- Add functional tests example\n- Add CI system example (e.g. using Jenkins or GoCD)\n- Add CD workflow \n- Add support for Git branching\n\n## Acknowledgements\n\nInspiration and ideas for this project were drawn from the following sources:\n\n- https://glyph.twistedmatrix.com/2015/03/docker-deploy-double-dutch.html\n- http://marmelab.com/blog/2014/09/10/make-docker-command.html\n- http://www.itnotes.de/docker/development/tools/2014/08/31/speed-up-your-docker-workflow-with-a-makefile/\n- https://hynek.me/articles/virtualenv-lives/\n\n","has_starred","hub_user","immutable_tags_settings",{"_75":11,"_76":77},"enabled","rules",[78],".*","is_automated","permissions",{"_82":21,"_83":11,"_84":11},"read","write","admin","user","storage_size",36020358015,"orgData","recentTags",[91],{"_92":44,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_50":118,"_119":94,"_120":33,"_121":56,"_57":122,"_123":124,"_125":109,"_126":118,"_127":66,"_128":21},"content_type","creator",294077,"digest","sha256:f54039b8ef31a8bd8344a9b89225cba5854d67ed5c1f0436c4972ec54c0a425d","full_size",170043411,"id",1274711,"images",[103],{"_104":105,"_95":96,"_106":107,"_108":109,"_110":111,"_112":113,"_114":107,"_115":-5,"_116":98,"_63":66,"_117":-5},"architecture","amd64","features","","last_pulled","2026-10-02T09:22:56.521258086Z","last_pushed","2018-04-12T18:32:31Z","os","linux","os_features","os_version","size","variant","2018-04-12T18:32:30.406535Z","last_updater","last_updater_username","media_type","latest","repository",388623,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","showSbxLogoOverride","sbxTrademarkText","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"selectedTag","attestationsUrl","routes/_layout.r.$namespace.$reponame.tags",{"_38":142,"_149":150,"_136":159,"_160":11},{"_40":143,"_42":144,"_45":46,"_47":48,"_49":11,"_50":51,"_52":53,"_54":145,"_57":35,"_32":33,"_58":59,"_60":44,"_61":62,"_63":64,"_65":66,"_67":-5,"_68":62,"_69":70,"_71":11,"_72":33,"_73":146,"_79":21,"_80":148,"_85":33,"_86":87},[],[44],[56],{"_75":11,"_76":147},[78],{"_82":21,"_83":11,"_84":11},"tags",{"_151":64,"_152":-5,"_153":-5,"_154":155},"count","next","previous","results",[156],{"_92":44,"_93":94,"_95":96,"_97":98,"_99":100,"_101":157,"_50":118,"_119":94,"_120":33,"_121":56,"_57":122,"_123":124,"_125":109,"_126":118,"_127":66,"_128":21},[158],{"_104":105,"_95":96,"_106":107,"_108":109,"_110":111,"_112":113,"_114":107,"_115":-5,"_116":98,"_63":66,"_117":-5},[],"canDeleteTags","actionData","errors"]

cloudhotspot/sample-django-app-dev

Tags for cloudhotspot/sample-django-app-dev