Google App Engine development with Docker

We have released a Docker Container for Google App Engine development.

• https://github.com/essa/docker-gae-python
• https://github.com/essa/docker-gae-python-extra

docker-gae-python is the GAE sdk for python + library and compiler, and docker-gae-python-extra is packed with the tools you are using.

How to use

Both start as follows,

sudo docker run -d -p 2022:22 -p 8080:8080 -v (Absolute path to the project root):/home/gae:rw essa/gae-python-extra /usr/sbin/sshd -D

Log in and use as follows. The initial password is python.

ssh -p 2022 gae@localhost

The following command will launch the sample app.

python /usr/local/google_appengine/dev_appserver.py /usr/local/google_appengine/demos/python/guestbook --port 8080 --host 0.0.0.0

From the host, you can access it at http: // localhost: 8080 /.

If you publish 8080 on the host firewall, you can access it from the outside. Since the Dockerfile with the password is published, please change the password when publishing 2022 of the ssh port to the outside.

Impressions of Docker

I've tried Docker for the first time and I think it's certainly useful.

The environment of GAE SDK for python is relatively easy to create, but since the project I'm doing now uses closureCompiler, SASS, and casper.js (phantom.js), the execution environment of ruby, java, and node.js is also available. You will need. It was difficult to create an environment where all of this works from scratch, and I was worried about how to write the explanation, but if I publish it as an image of Docker, it will be ready soon.

Even if you can't publish the image, if you attach the Dockerfile to the project, it will take some time, but you can create the same environment with a single docker build command.

For now, it may be difficult to create an execution environment for Docker, but if the cloud that can use coreos becomes widespread, it will be possible soon.

Creating a Dockerfile is almost the same as writing a shell script for building an environment, but since it commits the file system image of the execution result for each line of the RUN command, when it is re-executed, it automatically starts from the corrected line. Thank you for restarting.

What I didn't expect in the positive direction when I actually used it was that this feature made writing a Dockerfile easier than I expected.

This kind of script and environment construction tool

1. Write it all and run the test
2. There is a time-consuming process that works
3. Corrected a minor mistake near the end
4. It takes time to re-execute everything, so execute only the corrected part and check
5. Then it works, but when I run it from the beginning I get an error

So, if you do everything honestly from the beginning, it takes time, so it tends to be a pattern of tears if you mistakenly delete the script that you are about to write by mistake in the process of initializing the environment.

I think that the main purpose of using Docker is to quickly start up a machine for production operation, but I feel that it can also be used to prepare a development environment and share it.

TIPS

I don't know much yet, but I'll make a note of where I stumbled.

• -v (host-side path): (path in Container): You can easily mount a directory on the host with rw. Files that you want to keep, such as sources and DBs, can be left on the host in this way, and you can delete the virtual image.
• If you have a lot of virtual images and don't understand, look at docker images --tree and delete the ID of the tail with docker rmi, and all the images connected to it will disappear.
• docker rm deleted the container, docker rmi deleted the image, was initially confused.
• When building, docker build ...-<Dockerfile finishes faster (when the current directory is full of files)