[{"_1":2,"_154":-5,"_155":-5},"loaderData",{"_3":4,"_13":14,"_21":22,"_133":134},"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":-5,"_85":86,"_124":-5,"_125":11,"_126":17,"_127":11,"_128":-5,"_129":11,"_130":-5,"_131":132},"canonicalUrl","https://hub.docker.com/r/pwera/openwhisk-dev/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","pwera","reponame","openwhisk-dev","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":40,"_57":58,"_59":60,"_61":62,"_63":-5,"_64":58,"_65":66,"_67":11,"_68":29,"_69":70,"_75":11,"_76":77,"_81":29,"_82":83},"categories",[],"content_types",[40],"image","date_registered","2020-04-07T08:26:22.262359Z","description","","is_private","last_updated","2020-11-05T17:01:52.22752Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[52],"application/vnd.docker.container.image.v1+json","name","pull_count",918,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","# Docker\n\nNotes & code & tools for Docker\n\n\n## The story\n- Docker command line is talking with server.\n- In 2017 management commands cames in\n- An Image is the application we want to run.\n- A container is an instance of that image running as a process.\n- Docker's default image registry is dockerhub.\n- Containers only run as long as the command that it ran on startup run. Default command is defined in Dockerfile.\n- Image is the application binaries and dependencies for app and the metadata on how to run it. Image is an ordered collection of root filesystem changes and the corresponding execution parameters for use within a container runtime. Image is not complete OS, no kernel, kernel modules (e.g. drivers).\n- Containers use Linux security primitives such as Linux kernel namespaces to sandbox different applications running on the same computers \nand control groups (cgroups) in order to avoid the noisy-neighbor problem, where one bad application is using all the available resources of a server and starving all other applications.\nContainers are only possible due to the fact that the Linux OS provides some primitives, such as namespaces, control groups, layer capabilities, \nand more, all of which are leveraged in a very specific way by the container runtime and the Docker engine. \n\n- Linux kernel namespaces, such as process ID (pid) namespaces or network (net) namespaces, allow Docker to encapsulate or sandbox processes that run inside the container. \n\n- Control Groups make sure that containers cannot suffer from the noisy-neighbor syndrome, where a single application running in a container \ncan consume most or all of the available resources of the whole Docker host. \nControl Groups allow Docker to limit the resources, such as CPU time or the amount of RAM, that each container is allocated.\n\n\n## Commands\n``` \ndocker version \n``` \n``` \ndocker info\n``` \n``` \ndocker container run --publish 80:80 nginx\n```\nIn the background docker engine looked for an image called nginx, and pulled down the latest image from Docker hub, and then it started as a new process in a new container.\nGive a virtual IP on a private network inside docker engine.\nAlso expose localport 80 on host and send all trafiic\nfrom it to executable on port 80.\nStatic IP's and using IP's for talking to containers is an anti-pattern.\n\n``` \ndocker container run --publish 80:80 --detach nginx\n``` \nDetach tells Docker to run container in the background\n\n``` \ndocker container ls\n``` \nRunning container status\n``` \ndocker container ls -a\n``` \nAll container status\n``` \ndocker container start ...\n``` \nStart existing stopped container\n``` \ndocker container run --publish 80:80 --detach --name nginx nginx\n``` \nSet name for container\n``` \ndocker container logs nginx\n``` \nContainer logs\n``` \ndocker container top nginx\n``` \nProcesess inside container\n``` \ndocker container rm nginx\n```\nRemove stopped containers.\n``` \ndocker container rm -f nginx\n```\nRemove containers.\n``` \ndocker run --name mongo \ndocker container top mongo ( ps -aux | grep mongo )\n```\nList of running processes in specific container.\n\n``` \ndocker container inspect \n```\nDetails of one container config.\n\n``` \ndocker container inspect --format '{{ .NetworkSettings.IPAddress }}' webhost\n```\nIPAddress of one container.\n\n``` \ndocker container inspect -f \"{{json .State}}\" trivia | jq .\n``` \nPrint formatted state of the cointainer.\n\n``` \ndocker container stats (optional )\n```\nPerformance stats for all containers in realtime stream.\n\n``` \ndocker container run -it \n```\nRun new container interactively.\n-t pseudo-tty(teletypewriter), simulates a real terminal like ssh\n-i interactive, keep session open to receive terminal input\n\n``` \n docker container exec -it \n```\nRun additional command in existing container.\n\n## Single-Host Network\nDocker has defined a very simple\nnetworking model, the so-called container network model (CNM), to specify the\nrequirements that any software that implements a container network has to fulfill.\n\nThis network implementation is based on the Linux bridge.\nWhen the Docker daemon runs for the first time, it creates a Linux bridge and calls\nit docker0.\nDocker then creates a network with this Linux bridge and calls the network bridge. All the\ncontainers that we create on a Docker host and that we do not explicitly bind to another\nnetwork leads to Docker automatically attaching to this bridge network.\n\nIP address management (IPAM) block. IPAM is a\npiece of software that is used to track IP addresses that are used on a computer. The\nimportant part of the IPAM block is the Config node with its values for Subnet and\nGateway. The subnet for the bridge network is defined by default as 172.17.0.0/16. This\nmeans that all containers attached to this network will get an IP address assigned by\nDocker that is taken from the given range, which is 172.17.0.2 to\n172.17.255.255. The 172.17.0.1 address is reserved for the router of this network\nwhose role in this type of network is taken by the Linux bridge. We can expect that the very\nfirst container that will be attached to this network by Docker will get\nthe 172.17.0.2 address\n\nBy default, only egress traffic is allowed, and all ingress is blocked. What this means is\nthat while containerized applications can reach the internet, they cannot be reached by any\noutside traffic. Each container attached to the network gets its own virtual ethernet (veth)\nconnection with the bridge. \n\n\n``` \ndocker container run -p 80:80 --name webhost -d \ndocker container port webhost\n```\nWhat ports are open in container.\nEach container connect to a private virtual network \"bridge\", and that virtual network is automatically attached to Ethernet interface on host.\nEach virtual network routes through NAT firewall on host IP.\nAll containers on a virtual network can talk to each other without -p.\nUse different Docker network drivers to gain new abilities.\n\n``` \ndocker network ls\n```\nShow networks\n\n``` \ndocker network inspect \n```\nInspect a network\n\n``` \ndocker network create --driver\n```\nCreate a network with optional driver.\n\n``` \ndocker network connect\ndocker network disconnect\n```\nAttach and detach a network to/from on running container.\nBridge network is default docker virtual network, which is NAT'ed behind the host IP.\nHost network is faster by skipping virtual networks but sacrifices security of container model.\nNetork driver is build-in or 3rd party extension that give you virtual network features.\n``` \ndocker network create my_network\ndocker container run -d --name nginx --network my_network nginx\ndocker network inspect my_network\ndocker network connect old_nginx\ndocker network inspect my_network\ndocker network inspect bridge\n```\nold_nginx is now attached into two networks.\n\nAutomatic DNS Naming\nDocker deamon has a build-in DNS server that containers use by default.\nContainers in the same virtuall network can talk with its name.\nDocker defaults the hostname to the container's name but we can set aliases.\n\n``` \ndocker network create my_network\ndocker container run -it --rm --name nginx_old --network my_network nginx:alpine\ndocker container run -it --rm --name new_nginx --network my_network nginx:alpine ping nginx_old \n```\n\nDNS Round Robin\n\n``` \ndocker container run -d --rm --name el1 --network my_network --network-alias search elasticsearch:2\ndocker container run -d --rm --name el2 --network my_network --network-alias search elasticsearch:2\ndocker container run -it --rm --name alpine1 --net my_network nginx:alpine ping search:9200\ndocker container run -it --rm --name centos1 --net my_network centos curl -s search:9200\ndocker container run -it --rm --name alpine2 --net my_network alpine nslookup search\n```\n\n```\ndocker network create --driver bridge --subnet \"10.1.0.0/16\" test-net\n```\nspecify our own subnet range when creating a network\n\n## Images\nDocker uses a Union file system to present a series of file system changes as an actual file system.\n``` \ndocker history nginx:latest\n```\nShow layers of changes made in image.\n\n``` \ndocker image inspect nginx:latest\n```\nReturns JSON metadata about the image.\n\n``` \ndocker image tag nginx:latest pwera/nginx:1.0.0\n```\nTag an image\n\n``` \ndocker image build . -t myimage\n```\nBuild image from Dockerfile\n\n``` \ndocker image prune\n```\n Clean up just \"dangling\" images\n\n``` \ndocker system prune\n```\nClean up everything\n\n``` \ndocker system df\n```\nSee space usage\n\n\n```\ndocker container diff sample\n```\nIf we want to see what has changed in our container in relation to the base image.\n\n```\ndocker container run --name test -it --log-driver none busybox sh -c 'for N in 1 2 3; do echo \"Hello $N\"; done'\n```\nDocker supports several different graph drivers using a pluggable architecture. The preferred driver is overlay2, followed by overlay.\n\n\n`FROM` scratch is a no-op in the Dockerfile, and as such does not generate a layer in the resulting container image.\n\n`ADD` keyword also lets us copy and unpack TAR files, as well as providing a URL as a source for the files and folders to copy.\n\nFrom a security perspective, it is important to know that, by default, all files and folders inside the image will have a user ID (UID) and a group ID (GID) of 0. \nThe good thing is that for both `ADD` and `COPY`, we can change the ownership that the files will have inside the image using the optional --chown flag, as follows\n\n```ADD --chown=11:22 ./data/web* /app/data/```\n\nThe `CMD` and `ENTRYPOINT` keywords are special. \nWhile all other keywords defined for a Dockerfile are executed at the time the image is built by the Docker builder, these two are actually definitions of what will happen when a container is started from the image we define\n\n```\ndocker container run --rm -it --entrypoint /bin/sh pinger\n```\nOverride what's defined in the `ENTRYPOINT`\n\nIf you leave `ENTRYPOINT` undefined, then it will have the default value of /bin/sh -c, and whatever the value of `CMD` is will be passed as a string to the shell command.\n\n```\ndocker container run --rm -it --env-file ./development.config alpine sh -c \"export\"\n ```\n Override Environmentals.\n\n```\n$ docker image build \\ \n--build-arg BASE_IMAGE_VERSION=12.7-alpine \\ \n-t my-node-app-test .\n```\n Override Dockerfile arguments.\n\n ```\ndocker container run --rm -it \\\n-v $(pwd):/usr/src/app \\\n-w /usr/src/app \\\nperl:slim sh -c \"cat sample.txt | perl -lpe 's/^\\s*//'\"\n```\nRemove spaces from file, using perl\n\n```\ndocker container run --rm \\\n --name shellinabox \\\n -p 4200:4200 \\\n -e SIAB_USER=gnschenker \\\n -e SIAB_PASSWORD=top-secret \\\n -e SIAB_SUDO=true \\\n -v `pwd`/dev:/usr/src/dev \\\n sspreitzer/shellinabox:latest\n ```\n Running terminal in a remote container and accessing it via HTTPS\n\n``` \ndocker container run --tty -d \\\n --name billing \\\n --read-only \\\n alpine /bin/sh\n ```\nSet read-only filesystem.\n\n```\ndocker container ps -a \\\n--format \"table {{.Names}}\\t{{.Image}}\\t{{.Status}}\"\n```\nPrint formatted Name Image & Status.\n\n```\ndocker image build -t my-centos -f Dockerfile .\n```\nSending build context to Docker daemon 2.048kB\nThe first thing the builder does is package the files in the current build context, excluding the files and folder mentioned in the .dockerignore file (if present), and sends the resulting .tar file to the Docker daemon.\n\n```\nFROM alpine:3.7 AS build\nRUN apk update && \\ \napk add --update alpine-sdk\nRUN mkdir /appWORKDIR /app\nCOPY . /appRUN mkdir bin\nRUN gcc hello.c -o bin/hello \nFROM alpine:3.7COPY --from=build /app/bin/hello /app/helloCMD /app/hello\n```\nMultistage build. In this case it's a reduction in size by a factor of 40. A smaller image has many advantages, such as a smaller attack surface area for hackers, reduced memory and disk consumption, faster startup times of the corresponding containers, and a reduction of the bandwidth needed to download the image from a registry, such as Docker Hub.\n\n```\n-v /var/run/docker.sock:/var/run/docker.sock\n```\nMounting the Docker socket into the container, so Docker can be accessed from within the container. Docker socket into the builder, the Docker commands act on the host.\nIt is important to note that here we are not talking about running the\nDocker Engine inside the container but rather only the Docker CLI and\nbind-mount the Docker socket from the host into the container so that the\nCLI can communicate with the Docker Engine running on the host\ncomputer. This is an important distinction. Running the Docker Engine\ninside a container, although possible, is not recommended.\n\n```\ndocker image ls --filter dangling=false --filter \"reference=*/*/*:latest\"\n```\nFilter only outputs images that are not dangling, that is, real images whose\nfully qualified name is of the form /:, and\nthe tag is equal to latest.\n\n```\n docker container run --rm -it \\\n --name stress-test \\\n --memory 512M \\\n ubuntu:19.04 /bin/bash\n apt-get update && apt-get install -y stress\n stress -m 4\n ```\n Limiting resources consumed by a container\npossibility of limiting the resources a single container can consume at. This includes\nCPU and memory consumption. Use stress to simulate four workers, which try to malloc() memory in blocks of 256MB.\nIn the Terminal running Docker stats, observe how the value for MEM USAGE approaches\nbut never exceeds LIMIT. This is exactly the behavior we expected from Docker. Docker\nuses Linux cgroups to enforce those limits.\n\n\n```\ndocker container run --rm -it --network none alpine:latest /bin/sh\n```\n\nSometimes, we need to run a few application services or jobs that do not need any network\nconnection at all to execute the task at hand. It is strongly advised that you run those\napplications in a container that is attached to the none network. This container will be\ncompletely isolated, and is thus safe from any outside access.\n\n```\ndocker container run --name web -P -d nginx:alpine\n```\nWe can let Docker decide which host port our container port shall be\nmapped to. Docker will then select one of the free host ports in the range of\n32xxx. This automatic mapping is done by using the `-P` parameter\n\nWhen using the UDP protocol for communication over a certain port, the publish\nparameter will look like `-p 3000:4321/udp`. Note that if we want to allow communication with both `TCP` and `UDP` protocols over the same port, then we have to map each protocol separately.\n\nThere is an important difference between running two containers attached to the same network and two containers running in the same network namespace. In both cases, the containers can freely communicate with each other, but in the latter case, the communication happens over localhost.\nThe container has its own virtual network stack, as does the host. Therefore, container ports and host ports exist completely independently and by default have nothing in common at all.\n\n\n\n## Persistent Data\nContainers are usually immutable and ephemeral\nhttps://www.oreilly.com/ideas/an-introduction-to-immutable-infrastructure\nDocker volumes are a configuration option for a container that creates a special location outside of that container's union file system to store unique data. This preserves it across container removals and allows us to attach it to whatever container we want. And the container just sees it like a local file path.\nBind mounts are simply us sharing or mounting a host directory, or file, into a container. \n \nThe default volume driver is the so-called local driver, which stores the data locally in the host filesystem.\n\nVolumes\n``` Dockerfile:\n...\nVOLUME /var/lib/something\n...\n```\nVolumes needs manual deletion. Use this if data is more important then container.\n\n``` \ndocker volume ls\n```\nVolumes lives longer then containers.\n\nNamed Volumes \n``` \ndocker container run -d -v myimage-volume:/var/lib/something nginx\ndocker volume ls\ndocker volume inspect myimage-volume\n```\nThe content that is already there is replaced by the content of the host folder.\n\n\n``` \ndocker volume create psql-data2\ndocker container run -d --rm --name pg1 -v psql-data2:/var/lib/postgresql/data postgres:9.6.1\ndocker container stop pg1\ndocker container run -d --rm --name pg2 -v psql-data2:/var/lib/postgresql/data postgres:9.6.2\n```\n\n\nBind Mounts\n``` \n... run -v ${pwd}:/path/inside/container\n```\nMaps a host file or directory to a container file or directory. Two locations pointing to the same files. \nCan't use in Dockerfile, must be at container run stage.\nWe can define as readonly.\n\n``` \ndocker run --rm --name serv1 -p 80:80 -v ${pwd}:/site bretfisher/jekyll-serve\n```\n\n## Docker Compose\n- Create one-liner developer environment startups.\n- YAML fomratted.\n- CLI tool docker-compose for local and testing purposes.\n- Custom compose file should be used with -f flag.\n\n``` \n version: '3.1' # if no version is specificed then v1 is assumed. Recommend v2 minimum\n\nservices: # containers. same as docker run\n servicename: # a friendly name. this is also DNS name inside network\n image: # Optional if you use build:\n command: # Optional, replace the default CMD specified by the image\n environment: # Optional, same as -e in docker run\n volumes: # Optional, same as -v in docker run\n servicename2:\n\nvolumes: # Optional, same as docker volume create\n\nnetworks: # Optional, same as docker network create\n```\n\n\n``` \n version: '3.1'\n\nservices:\n jekyll:\n image: bretfisher/jekyll-serve\n volumes:\n - .:/site\n ports:\n - '80:4000'\n```\n\nCompose can build custom images\n\n \n``` \ndocker-compose build\n```\n\n``` \n version: '3.1'\n\nservices:\n proxy:\n build:\n context: .\n dockerfile: nginx.Dockerfile\n ports:\n - '80:80'\n```\nBuild custom image on docker-compose up command with ${folder_name}/proxy name\n\n``` \n version: '3.1'\n\nservices:\n proxy:\n build:\n context: .\n dockerfile: nginx.Dockerfile\n image: proxxy\n ports:\n - '80:80'\n```\nBuild custom image on docker-compose up command with proxxy name\n\n```\ndocker-compose config\n```\n\nCommand docker-compose config shows how compose will look with the variables filled in.\n\n```\ndocker-compose -f docker-compose.yml -f docker-compose-ci.yml up -d --\nbuild\n```\nUsing Compose overrides.\n\n\n## Docker Swarm\nAn orchestrator is an infrastructure software that is used to run and manage containerized applications in a cluster while making sure that these applications are in their desired state at all times. \n\nThe tasks of an orchestrator:\n- Reconciling the desired state\n- Replicated and global services\n- Service discovery\n- Routing\n- Load balancing\n- Scaling\n- Self-healing\n- Zero downtime deployments\n- Affinity and location awareness\n- Security\n- Role-based access control (RBAC)\n- Secrets\n- Content trust\n\nThe architecture of a Docker Swarm from a 30,000-foot view consists of two main parts—a raft consensus group of an odd number of manager nodes, and a group of worker nodes that communicate with each other over a gossip network, also called the control plane.\n\nThere are two quite different types of services that we might want to run in a cluster that is\nmanaged by an orchestrator. They are replicated and global services. A replicated service is a\nservice that is required to run in a specific number of instances, say 10. A global service, in\nturn, is a service that is required to have exactly one instance running on every single\nworker node of the cluster. I have used the term worker node here. In a cluster that is\nmanaged by an orchestrator, we typically have two types of nodes, managers and workers.\nA manager node is usually exclusively used by the orchestrator to manage the cluster and\ndoes not run any other workload. Worker nodes, in turn, run the actual applications.\nSo, the orchestrator makes sure that, for a global service, an instance of it is running on\nevery single worker node, no matter how many there are. We do not need to care about the\nnumber of instances, but only that on each node, it is guaranteed to run a single instance of\nthe service.\nOnce again, we can fully rely on the orchestrator to handle this. In a replicated service, we\nwill always be guaranteed to find the exact desired number of instances, while for a global\nservice, we can be assured that on every worker node, there will always run exactly one\ninstance of the service. The orchestrator will always work as hard as it can to guarantee this\ndesired state.\n\n`In Kubernetes, a global service is also called a DaemonSet.`\n\nEach Docker Swarm needs to include at least one manager node. For high availability reasons, we should have more than one manager node in a Swarm. This is especially true for production or production-like environments. If we have more than one manager node, then these nodes work together using the Raft consensus protocol. The `Raft` consensus protocol is a standard protocol that is often used when multiple entities need to work together and always need to agree with each other as to which activity to execute next.\n\nThe manager nodes are not only responsible for managing the Swarm but also for\nmaintaining the state of the Swarm. What do we mean by that? When we talk about the state of the Swarm we mean all of the information about it—for example, how many nodes are in the Swarm and what are the properties of each node, such as name or IP address. We also mean what containers are running on which node in the Swarm and more. What, on the other hand, is not included in the state of the Swarm is data produced by the application services running in containers on the Swarm. This is called application data and is definitely not part of the state that is managed by the manager nodes.\n\nAll of the Swarm states are stored in a high-performance key-value store (kv-store) on each manager node. That's right, each manager node stores a complete replica of the whole Swarm state. This redundancy makes the Swarm highly available. If a manager node goes down, the remaining managers all have the complete state at hand.\n\nWorker nodes communicate with each other over the so-called control plane. They use the gossip protocol for their communication. This communication is asynchronous, which means that, at any given time, it is likely that not all worker nodes are in perfect sync. \n\nIt is mostly information that is needed for service discovery and routing, that is, information about which containers are running on with nodes and more\n\n`Swarm` is a clustering solution build inside Docker\nControl Plane is how orders get sent around the Swarm.\nA single service can have multiple tasks and each one of those tasks will launch a container.\n``` \ndocker service create\n```\n On Manager Node\n- API Accept command from client and creates service object\n- Orchestrator Reconcillaion loop for service objects and create tasks\n- Allocator Allocates IP addresses to tasks\n- Scheduler Assign nodes to tasks\n- Dispatcher Check in on workers\nOn Worker node\n- workers Connects to dispatcher to check on assigned tasks\n- Executor Executes tasks assigned to worker node\n\n### Services\nA Swarm service is an abstract thing. It is a description of the desired state of an application\nor application service that we want to run in a Swarm. The Swarm service is like a manifest\ndescribing such things as the following:\nName of the service\nImage from which to create the containers\nNumber of replicas to run\nNetwork(s) that the containers of the service are attached to\nPorts that should be mapped\n\n### Task\nService corresponds to a description of the desired state in which an application service should be at all times. Part of that description was the number of replicas the service should be running. Each replica is represented by a task. In this regard,\na Swarm service contains a collection of tasks. On Docker Swarm, a task is the atomic unit of deployment. Each task of a service is deployed by the Swarm scheduler to a worker node. The task contains all of the necessary information that the worker node needs to run a\ncontainer based on the image, which is part of the service description. Between a task and a container, there is a one-to-one relation. The container is the instance that runs on the worker node, while the task is the description of this container as a part of a Swarm service.\n\n``` \ndocker swarm init\n```\n- Creates Root Signing Certificate created for Swarm\n- Certificate is issued for first Manager node\n- Join tokens are created\nRaft Consensus Database is created to store CA, configs and secrets.\nProtocol to ensure consistency between nodes. I created database on disc, and stores the configuration of the Swarm.\n\n\n``` \ndocker node ls\n```\nDocker node ## can promote workers to managers and demoting them.\n\n``` \ndocker service create slpine ping 8.8.8.8\n```\nReturns service ID, with one replica and random name.\n\n``` \ndocker service ps \n```\nCan see which node was applied.\n\n``` \ndocker serivce update --replicas 3\n```\nScalle up to 3 replicas.\n\n\n``` \ndocker update\n```\nAllow to update certain variable on running contain","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",889777420,"orgData","recentTags",[87],{"_88":40,"_89":90,"_91":92,"_93":94,"_95":96,"_46":113,"_114":90,"_115":29,"_116":52,"_53":117,"_118":119,"_120":104,"_121":113,"_122":62,"_123":17},"content_type","creator",4967467,"full_size",889761251,"id",94379741,"images",[97],{"_98":99,"_100":101,"_102":44,"_103":104,"_105":106,"_107":108,"_109":44,"_110":-5,"_111":92,"_59":62,"_112":-5},"architecture","amd64","digest","sha256:d7d712537b0794b046d7ca210b6e4a0b878d2b6bcbc4b2d22122059a3cbe5c0e","features","last_pulled","2026-09-24T20:07:31.18349699Z","last_pushed","2020-04-07T09:20:36Z","os","linux","os_features","os_version","size","variant","2020-11-05T17:01:51.014544Z","last_updater","last_updater_username","media_type","latest","repository",8786737,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","showSbxLogoOverride","sbxTrademarkText","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"routes/_layout.r.$namespace.$reponame.tags",{"_34":135,"_142":143,"_131":152,"_153":11},{"_36":136,"_38":137,"_41":42,"_43":44,"_45":11,"_46":47,"_48":49,"_50":138,"_53":31,"_28":29,"_54":55,"_56":40,"_57":58,"_59":60,"_61":62,"_63":-5,"_64":58,"_65":66,"_67":11,"_68":29,"_69":139,"_75":11,"_76":141,"_81":29,"_82":83},[],[40],[52],{"_71":11,"_72":140},[74],{"_78":17,"_79":11,"_80":11},"tags",{"_144":60,"_145":-5,"_146":-5,"_147":148},"count","next","previous","results",[149],{"_88":40,"_89":90,"_91":92,"_93":94,"_95":150,"_46":113,"_114":90,"_115":29,"_116":52,"_53":117,"_118":119,"_120":104,"_121":113,"_122":62,"_123":17},[151],{"_98":99,"_100":101,"_102":44,"_103":104,"_105":106,"_107":108,"_109":44,"_110":-5,"_111":92,"_59":62,"_112":-5},[],"canDeleteTags","actionData","errors"]

pwera/openwhisk-dev

Tags for pwera/openwhisk-dev