[{"_1":2,"_175":-5,"_176":-5},"loaderData",{"_3":4,"_17":18,"_25":26,"_150":151},"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":21,"_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,"_139":-5,"_140":11,"_141":21,"_142":11,"_143":-5,"_144":11,"_145":-5,"_146":147,"_148":91,"_149":-7},"canonicalUrl","https://hub.docker.com/r/sylhare/linux_tweet_app/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","sylhare","reponame","linux_tweet_app","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":11,"_80":81,"_85":33,"_86":87},"categories",[],"content_types",[44],"image","date_registered","2018-07-26T17:23:52.197736Z","description","Docker tutorial from https://training.play-with-docker.com/beginner-linux/","is_private","last_updated","2018-07-26T17:24:00.369255Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[56],"application/vnd.docker.container.image.v1+json","name","pull_count",103,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","Docker for Beginners - Linux\nOct 25, 2016 • @mikegcoleman\n\nIn this lab, we will look at some basic Docker commands and a simple build-ship-run workflow. We’ll start by running some simple containers, then we’ll use a Dockerfile to build a custom app. Finally, we’ll look at how to use bind mounts to modify a running container as you might if you were actively developing using Docker.\n\nDifficulty: Beginner (assumes no familiarity with Docker)\n\nTime: Approximately 30 minutes\n\nTasks:\n\nTask 0: Prerequisites\nTask 1: Run some simple Docker containers\nTask 2: Package and run a custom app using Docker\nTask 3: Modify a Running Website\nTask 0: Prerequisites\nYou will need all of the following to complete this lab:\n\nA clone of the lab’s GitHub repo.\nA DockerID.\nClone the Lab’s GitHub Repo\nUse the following command to clone the lab’s repo from GitHub (you can click the command or manually type it). This will make a copy of the lab’s repo in a new sub-directory called linux_tweet_app.\n\n git clone https://github.com/dockersamples/linux_tweet_app\nMake sure you have a DockerID\nIf you do not have a DockerID (a free login used to access Docker Cloud, Docker Store, and Docker Hub), please visit Docker Cloud and register for one. You will need this for later steps.\n\nTask 1: Run some simple Docker containers\nThere are different ways to use containers. These include:\n\nTo run a single task: This could be a shell script or a custom app.\nInteractively: This connects you to the container similar to the way you SSH into a remote server.\nIn the background: For long-running services like websites and databases.\nIn this section you’ll try each of those options and see how Docker manages the workload.\n\nRun a single task in an Alpine Linux container\nIn this step we’re going to start a new container and tell it to run the hostname command. The container will start, execute the hostname command, then exit.\n\nRun the following command in your Linux console.\n\n docker container run alpine hostname\nThe output below shows that the alpine:latest image could not be found locally. When this happens, Docker automatically pulls it from Docker Hub.\n\nAfter the image is pulled, the container’s hostname is displayed (888e89a3b36b in the example below).\n\n Unable to find image 'alpine:latest' locally\n latest: Pulling from library/alpine\n 88286f41530e: Pull complete\n Digest: sha256:f006ecbb824d87947d0b51ab8488634bf69fe4094959d935c0c103f4820a417d\n Status: Downloaded newer image for alpine:latest\n 888e89a3b36b\nDocker keeps a container running as long as the process it started inside the container is still running. In this case the hostname process exits as soon as the output is written. This means the container stops. However, Docker doesn’t delete resources by default, so the container still exists in the Exited state.\n\nList all containers.\n\n docker container ls --all\nNotice that your Alpine Linux container is in the Exited state.\n\n CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES\n 888e89a3b36b alpine \"hostname\" 50 seconds ago Exited (0) 49 seconds ago awesome_elion\nNote: The container ID is the hostname that the container displayed. In the example above it’s 888e89a3b36b.\n\nContainers which do one task and then exit can be very useful. You could build a Docker image that executes a script to configure something. Anyone can execute that task just by running the container - they don’t need the actual scripts or configuration information.\n\nRun an interactive Ubuntu container\nYou can run a container based on a different version of Linux than is running on your Docker host.\n\nIn the next example, we are going to run an Ubuntu Linux container on top of an Alpine Linux Docker host (Play With Docker uses Alpine Linux for its nodes).\n\nRun a Docker container and access its shell.\n\n docker container run --interactive --tty --rm ubuntu bash\nIn this example, we’re giving Docker three parameters:\n\n--interactive says you want an interactive session.\n--tty allocates a pseudo-tty.\n--rm tells Docker to go ahead and remove the container when it’s done executing.\nThe first two parameters allow you to interact with the Docker container.\n\nWe’re also telling the container to run bash as its main process (PID 1).\n\nWhen the container starts you’ll drop into the bash shell with the default prompt root@:/#. Docker has attached to the shell in the container, relaying input and output between your local session and the shell session in the container.\n\nRun the following commands in the container.\n\nls / will list the contents of the root director in the container, ps aux will show running processes in the container, cat /etc/issue will show which Linux distro the container is running, in this case Ubuntu 16.04.4 LTS.\n\nls /\nps aux\ncat /etc/issue\nType exit to leave the shell session. This will terminate the bash process, causing the container to exit.\n\n exit\nNote: As we used the --rm flag when we started the container, Docker removed the container when it stopped. This means if you run another docker container ls --all you won’t see the Ubuntu container.\n\nFor fun, let’s check the version of our host VM.\n\n cat /etc/issue\nYou should see:\n\n Welcome to Alpine Linux 3.6\n Kernel \\r on an \\m (\\l)\nNotice that our host VM is running Alpine Linux, yet we were able to run an Ubuntu container. As previously mentioned, the distribution of Linux inside the container does not need to match the distribution of Linux running on the Docker host.\n\nHowever, Linux containers require the Docker host to be running a Linux kernel. For example, Linux containers cannot run directly on Windows Docker hosts. The same is true of Windows containers - they need to run on a Docker host with a Windows kernel.\n\nInteractive containers are useful when you are putting together your own image. You can run a container and verify all the steps you need to deploy your app, and capture them in a Dockerfile.\n\nYou can commit a container to make an image from it - but you should avoid that wherever possible. It’s much better to use a repeatable Dockerfile to build your image. You’ll see that shortly.\n\nRun a background MySQL container\nBackground containers are how you’ll run most applications. Here’s a simple example using MySQL.\n\nRun a new MySQL container with the following command.\n\n docker container run \\\n --detach \\\n --name mydb \\\n -e MYSQL_ROOT_PASSWORD=my-secret-pw \\\n mysql:latest\n--detach will run the container in the background.\n--name will name it mydb.\n-e will use an environment variable to specify the root password (NOTE: This should never be done in production).\nAs the MySQL image was not available locally, Docker automatically pulled it from Docker Hub.\n\n Unable to find image 'mysql:latest' locallylatest: Pulling from library/mysql\n aa18ad1a0d33: Pull complete\n fdb8d83dece3: Pull complete\n 75b6ce7b50d3: Pull complete\n ed1d0a3a64e4: Pull complete\n 8eb36a82c85b: Pull complete\n 41be6f1a1c40: Pull complete\n 0e1b414eac71: Pull complete\n 914c28654a91: Pull complete\n 587693eb988c: Pull complete\n b183c3585729: Pull complete\n 315e21657aa4: Pull complete\n Digest: sha256:0dc3dacb751ef46a6647234abdec2d47400f0dfbe77ab490b02bffdae57846ed\n Status: Downloaded newer image for mysql:latest\n 41d6157c9f7d1529a6c922acb8167ca66f167119df0fe3d86964db6c0d7ba4e0\nAs long as the MySQL process is running, Docker will keep the container running in the background.\n\nList the running containers.\n\n docker container ls\nNotice your container is running.\n\n CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES\n 3f4e8da0caf7 mysql:latest \"docker-entrypoint...\" 52 seconds ago Up 51 seconds 3306/tcp mydb\nYou can check what’s happening in your containers by using a couple of built-in Docker commands: docker container logs and docker container top.\n\n docker container logs mydb\nThis shows the logs from the MySQL Docker container.\n\n \n 2017-09-29T16:02:58.605004Z 0 [Note] Executing 'SELECT * FROM INFORMATION_SCHEMA.TABLES;' to get a list of tables using the deprecated partition engine. You may use the startup option '--disable-partition-engine-check' to skip this check.\n 2017-09-29T16:02:58.605026Z 0 [Note] Beginning of list of non-natively partitioned tables\n 2017-09-29T16:02:58.616575Z 0 [Note] End of list of non-natively partitioned tables\nLet’s look at the processes running inside the container.\n\n docker container top mydb\nYou should see the MySQL daemon (mysqld) is running in the container.\n\n PID USER TIME COMMAND\n 2876 999 0:00 mysqld\nAlthough MySQL is running, it is isolated within the container because no network ports have been published to the host. Network traffic cannot reach containers from the host unless ports are explicitly published.\n\nList the MySQL version using docker container exec.\n\ndocker container exec allows you to run a command inside a container. In this example, we’ll use docker container exec to run the command-line equivalent of mysql --user=root --password=$MYSQL_ROOT_PASSWORD --version inside our MySQL container.\n\n docker exec -it mydb \\\n mysql --user=root --password=$MYSQL_ROOT_PASSWORD --version\nYou will see the MySQL version number, as well as a handy warning.\n\n mysql: [Warning] Using a password on the command line interface can be insecure.\n mysql Ver 14.14 Distrib 5.7.19, for Linux (x86_64) using EditLine wrapper\nYou can also use docker container exec to connect to a new shell process inside an already-running container. Executing the command below will give you an interactive shell (sh) inside your MySQL container.\n\n docker exec -it mydb sh\nNotice that your shell prompt has changed. This is because your shell is now connected to the sh process running inside of your container.\n\nLet’s check the version number by running the same command again, only this time from within the new shell session in the container.\n\n mysql --user=root --password=$MYSQL_ROOT_PASSWORD --version\nNotice the output is the same as before.\n\nType exit to leave the interactive shell session.\n\n exit\nTask 2: Package and run a custom app using Docker\nIn this step you’ll learn how to package your own apps as Docker images using a Dockerfile.\n\nThe Dockerfile syntax is straightforward. In this task, we’re going to create a simple NGINX website from a Dockerfile.\n\nBuild a simple website image\nLet’s have a look at the Dockerfile we’ll be using, which builds a simple website that allows you to send a tweet.\n\nMake sure you’re in the linux_tweet_app directory.\n\n cd ~/linux_tweet_app\nDisplay the contents of the Dockerfile.\n\n cat Dockerfile\n FROM nginx:latest\n\n COPY index.html /usr/share/nginx/html\n COPY linux.png /usr/share/nginx/html\n\n EXPOSE 80 443 \n\n CMD [\"nginx\", \"-g\", \"daemon off;\"]\nLet’s see what each of these lines in the Dockerfile do.\n\nFROM specifies the base image to use as the starting point for this new image you’re creating. For this example we’re starting from nginx:latest.\nCOPY copies files from the Docker host into the image, at a known location. In this example, COPY is used to copy two files into the image: index.html. and a graphic that will be used on our webpage.\nEXPOSE documents which ports the application uses.\nCMD specifies what command to run when a container is started from the image. Notice that we can specify the command, as well as run-time arguments.\nIn order to make the following commands more copy/paste friendly, export an environment variable containing your DockerID (if you don’t have a DockerID you can get one for free via Docker Cloud).\n\nYou will have to manually type this command as it requires your unique DockerID.\n\nexport DOCKERID=\n\nEcho the value of the variable back to the terminal to ensure it was stored correctly.\n\n echo $DOCKERID\nUse the docker image build command to create a new Docker image using the instructions in the Dockerfile.\n\n--tag allows us to give the image a custom name. In this case it’s comprised of our DockerID, the application name, and a version. Having the Docker ID attached to the name will allow us to store it on Docker Hub in a later step\n. tells Docker to use the current directory as the build context\nBe sure to include period (.) at the end of the command.\n\n docker image build --tag $DOCKERID/linux_tweet_app:1.0 .\nThe output below shows the Docker daemon executing each line in the Dockerfile\n\n Sending build context to Docker daemon 32.77kB\n Step 1/5 : FROM nginx:latest\n latest: Pulling from library/nginx\n afeb2bfd31c0: Pull complete\n 7ff5d10493db: Pull complete\n d2562f1ae1d0: Pull complete\n Digest: sha256:af32e714a9cc3157157374e68c818b05ebe9e0737aac06b55a09da374209a8f9\n Status: Downloaded newer image for nginx:latest\n ---> da5939581ac8\n Step 2/5 : COPY index.html /usr/share/nginx/html\n ---> eba2eec2bea9\n Step 3/5 : COPY linux.png /usr/share/nginx/html\n ---> 4d080f499b53\n Step 4/5 : EXPOSE 80 443\n ---> Running in 47232cb5699f\n ---> 74c968a9165f\n Removing intermediate container 47232cb5699f\n Step 5/5 : CMD nginx -g daemon off;\n ---> Running in 4623761274ac\n ---> 12045a0df899\n Removing intermediate container 4623761274ac\n Successfully built 12045a0df899\n Successfully tagged /linux_tweet_app:latest\nUse the docker container run command to start a new container from the image you created.\n\nAs this container will be running an NGINX web server, we’ll use the --publish flag to publish port 80 inside the container onto port 80 on the host. This will allow traffic coming in to the Docker host on port 80 to be directed to port 80 in the container. The format of the --publish flag is host_port:container_port.\n\n docker container run \\\n --detach \\\n --publish 80:80 \\\n --name linux_tweet_app \\\n $DOCKERID/linux_tweet_app:1.0\nAny external traffic coming into the server on port 80 will now be directed into the container on port 80.\n\nIn a later step you will see how to map traffic from two different ports - this is necessary when two containers use the same port to communicate since you can only expose the port once on the host.\n\nClick here to load the website which should be running.\n\nOnce you’ve accessed your website, shut it down and remove it.\n\n docker container rm --force linux_tweet_app\nNote: We used the --force parameter to remove the running container without shutting it down. This will ungracefully shutdown the container and permanently remove it from the Docker host.\n\nIn a production environment you may want to use docker container stop to gracefully stop the container and leave it on the host. You can then use docker container rm to permanently remove it.\n\nTask 3: Modify a running website\nWhen you’re actively working on an application it is inconvenient to have to stop the container, rebuild the image, and run a new version every time you make a change to your source code.\n\nOne way to streamline this process is to mount the source code directory on the local machine into the running container. This will allow any changes made to the files on the host to be immediately reflected in the container.\n\nWe do this using something called a bind mount.\n\nWhen you use a bind mount, a file or directory on the host machine is mounted into a container running on the same host.\n\nStart our web app with a bind mount\nLet’s start the web app and mount the current directory into the container.\n\nIn this example we’ll use the --mount flag to mount the current directory on the host into /usr/share/nginx/html inside the container.\n\nBe sure to run this command from within the linux_tweet_app directory on your Docker host.\n\n docker container run \\\n --detach \\\n --publish 80:80 \\\n --name linux_tweet_app \\\n --mount type=bind,source=\"$(pwd)\",target=/usr/share/nginx/html \\\n $DOCKERID/linux_tweet_app:1.0\nRemember from the Dockerfile, usr/share/nginx/html is where the html files are stored for the web app.\n\nThe website should be running.\n\nModify the running website\nBind mounts mean that any changes made to the local file system are immediately reflected in the running container.\n\nCopy a new index.html into the container.\n\nThe Git repo that you pulled earlier contains several different versions of an index.html file. You can manually run an ls command from within the ~/linux_tweet_app directory to see a list of them. In this step we’ll replace index.html with index-new.html.\n\n cp index-new.html index.html\nGo to the running website and refresh the page. Notice that the site has changed.\n\nIf you are comfortable with vi you can use it to load the local index.html file and make additional changes. Those too would be reflected when you reload the webpage. If you are really adventurous, why not try using exec to access the running container and modify the files stored there.\n\nEven though we’ve modified the index.html local filesystem and seen it reflected in the running container, we’ve not actually changed the Docker image that the container was started from.\n\nTo show this, stop the current container and re-run the 1.0 image without a bind mount.\n\nStop and remove the currently running container.\n\n docker rm --force linux_tweet_app\nRerun the current version without a bind mount.\n\n docker container run \\\n --detach \\\n --publish 80:80 \\\n --name linux_tweet_app \\\n $DOCKERID/linux_tweet_app:1.0\nNotice the website is back to the original version.\n\nStop and remove the current container\n\ndocker rm --force linux_tweet_app\nUpdate the image\nTo persist the changes you made to the index.html file into the image, you need to build a new version of the image.\n\nBuild a new image and tag it as 2.0\n\nRemember that you previously modified the index.html file on the Docker hosts local filesystem. This means that running another docker image build command will build a new image with the updated index.html\n\nBe sure to include the period (.) at the end of the command.\n\n docker image build --tag $DOCKERID/linux_tweet_app:2.0 .\nNotice how fast that built! This is because Docker only modified the portion of the image that changed vs. rebuilding the whole image.\n\nLet’s look at the images on the system.\n\n docker image ls\nYou now have both versions of the web app on your host.\n\n REPOSITORY TAG IMAGE ID CREATED SIZE\n /linux_tweet_app 2.0 01612e05312b 16 seconds ago 108MB\n /linux_tweet_app 1.0 bb32b5783cd3 4 minutes ago 108MB\n mysql latest b4e78b89bcf3 2 weeks ago 412MB\n ubuntu latest 2d696327ab2e 2 weeks ago 122MB\n nginx latest da5939581ac8 3 weeks ago 108MB\n alpine latest 76da55c8019d 3 weeks ago 3.97MB\nTest the new version\nRun a new container from the new version of the image.\n\n docker container run \\\n --detach \\\n --publish 80:80 \\\n --name linux_tweet_app \\\n $DOCKERID/linux_tweet_app:2.0\nCheck the new version of the website (You may need to refresh your browser to get the new version to load).\n\nThe web page will have an orange background.\n\nWe can run both versions side by side. The only thing we need to be aware of is that we cannot have two containers using port 80 on the same host.\n\nAs we’re already using port 80 for the container running from the 2.0 version of the image, we will start a new container and publish it on port 8080. Additionally, we need to give our container a unique name (old_linux_tweet_app)\n\nRun another new container, this time from the old version of the image.\n\nNotice that this command maps the new container to port 8080 on the host. This is because two containers cannot map to the same port on a single Docker host.\n\n docker container run \\\n --detach \\\n --publish 8080:80 \\\n --name old_linux_tweet_app \\\n $DOCKERID/linux_tweet_app:1.0\nView the old version of the website.\n\nPush your images to Docker Hub\nList the images on your Docker host.\n\n docker image ls -f reference=\"$DOCKERID/*\"\nYou will see that you now have two linux_tweet_app images - one tagged as 1.0 and the other as 2.0.\n\n REPOSITORY TAG IMAGE ID CREATED SIZE\n /linux_tweet_app 2.0 01612e05312b 3 minutes ago 108MB\n /linux_tweet_app 1.0 bb32b5783cd3 7 minutes ago 108MB\nThese images are only stored in your Docker hosts local repository. Your Docker host will be deleted after the workshop. In this step we’ll push the images to a public repository so you can run them from any Linux machine with Docker.\n\nDistribution is built into the Docker platform. You can build images locally and push them to a public or private registry, making them available to other users. Anyone with access can pull that image and run a container from it. The behavior of the app in the container will be the same for everyone, because the image contains the fully-configured app - the only requirements to run it are Linux and Docker.\n\nDocker Hub is the default public registry for Docker images.\n\nBefore you can push your images, you will need to log into Docker Hub.\n\n docker login\nYou will need to supply your Docker ID credentials when prompted.\n\n Username: \n Password: \n Login Succeeded\nPush version 1.0 of your web app using docker image push.\n\n docker image push $DOCKERID/linux_tweet_app:1.0\nYou’ll see the progress as the image is pushed up to Docker Hub.\n\n The push refers to a repository [docker.io//linux_tweet_app]\n 910e84bcef7a: Pushed\n 1dee161c8ba4: Pushed\n 110566462efa: Pushed\n 305e2b6ef454: Pushed\n 24e065a5f328: Pushed\n 1.0: digest: sha256:51e937ec18c7757879722f15fa1044cbfbf2f6b7eaeeb578c7c352baba9aa6dc size: 1363\nNow push version 2.0.\n\n docker image push $DOCKERID/linux_tweet_app:2.0\nNotice that several lines of the output say Layer already exists. This is because Docker will leverage read-only layers that are the same as any previously uploaded image layers.\n\n The push refers to a repository [docker.io//linux_tweet_app]\n 0b171f8fbe22: Pushed\n 70d38c767c00: Pushed\n 110566462efa: Layer already exists\n 305e2b6ef454: Layer already exists\n 24e065a5f328: Layer already exists\n 2.0: digest: sha256:7c51f77f90b81e5a598a13f129c95543172bae8f5850537225eae0c78e4f3add size: 1363\nYou can browse to https://hub.docker.com/r// and see your newly-pushed Docker images. These are public repositories, so anyone can pull the image - you don’t even need a Docker ID to pull public images. Docker Hub also supports private repositories.\n\nNext Step\nCheck out this introduction to orchestration with Docker Swarm Stack Introduction\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",44660006,"orgData","recentTags",[91,129],{"_92":44,"_93":94,"_95":96,"_97":98,"_99":100,"_50":118,"_119":94,"_120":33,"_121":56,"_57":122,"_123":124,"_125":109,"_126":118,"_127":66,"_128":21},"content_type","creator",2124820,"full_size",44633764,"id",31810740,"images",[101],{"_102":103,"_104":105,"_106":107,"_108":109,"_110":111,"_112":113,"_114":107,"_115":-5,"_116":96,"_63":66,"_117":-5},"architecture","amd64","digest","sha256:9c53f02b7b886153ff0aeb762ad153370b78988b82d0b1c0da3566feb081ffba","features","","last_pulled","2026-09-12T21:48:48.207150648Z","last_pushed","2018-07-26T17:24:00Z","os","linux","os_features","os_version","size","variant","2018-07-26T17:23:59.966856Z","last_updater","last_updater_username","media_type","2.0","repository",5791408,"tag_last_pulled","tag_last_pushed","tag_status","v2",{"_92":44,"_93":94,"_95":130,"_97":131,"_99":132,"_50":137,"_119":94,"_120":33,"_121":56,"_57":138,"_123":124,"_125":135,"_126":137,"_127":66,"_128":21},44633754,31810735,[133],{"_102":103,"_104":134,"_106":107,"_108":135,"_110":136,"_112":113,"_114":107,"_115":-5,"_116":130,"_63":66,"_117":-5},"sha256:0c846beb3bf79f2c4bbcbc9dbdfcccd1cc7fc0f77da68351142dce9c852d3813","2026-10-06T08:54:48.722521053Z","2018-07-26T17:23:52Z","2018-07-26T17:23:51.767708Z","1.0","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","showSbxLogoOverride","sbxTrademarkText","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"selectedTag","attestationsUrl","routes/_layout.r.$namespace.$reponame.tags",{"_38":152,"_159":160,"_146":173,"_174":11},{"_40":153,"_42":154,"_45":46,"_47":48,"_49":11,"_50":51,"_52":53,"_54":155,"_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":156,"_79":11,"_80":158,"_85":33,"_86":87},[],[44],[56],{"_75":11,"_76":157},[78],{"_82":21,"_83":11,"_84":11},"tags",{"_161":162,"_163":-5,"_164":-5,"_165":166},"count",2,"next","previous","results",[167,170],{"_92":44,"_93":94,"_95":96,"_97":98,"_99":168,"_50":118,"_119":94,"_120":33,"_121":56,"_57":122,"_123":124,"_125":109,"_126":118,"_127":66,"_128":21},[169],{"_102":103,"_104":105,"_106":107,"_108":109,"_110":111,"_112":113,"_114":107,"_115":-5,"_116":96,"_63":66,"_117":-5},{"_92":44,"_93":94,"_95":130,"_97":131,"_99":171,"_50":137,"_119":94,"_120":33,"_121":56,"_57":138,"_123":124,"_125":135,"_126":137,"_127":66,"_128":21},[172],{"_102":103,"_104":134,"_106":107,"_108":135,"_110":136,"_112":113,"_114":107,"_115":-5,"_116":130,"_63":66,"_117":-5},[],"canDeleteTags","actionData","errors"]

sylhare/linux_tweet_app

Tags for sylhare/linux_tweet_app