Hey Ingo, Yes, installing dependencies on each container will affect deployment time along with disk storage and CPU / RAM to one extent or another, so should be considered carefully.
As far as the GAE services in the context of a Flex app, the JVM, python environment, golang libraries etc. in the Flex context will connect to the services by their own means, presenting the same surface to user code. Each runtime is slightly different in how connection to App Engine APIs is provided and which APIs are available, and you should check this docs page <https://cloud.google.com/appengine/docs/flexible/custom-runtimes/about-custom-runtimes> as the starting point of an investigation. As far as services operating above the instance level, such as HTTP(S) load balancing, versioning, traffic splitting, per-version domain names, Cloud Debug/Trace, logging, and the rest, these operate in a similarly-transparent way, often requiring no extra work or tuning, although the underlying implementation details are of course distinct and there may be some differences here and there. The documentation is a great place to start, and if more concrete questions come up, don't hesitate to post them! It would be hard to list all aspects of each of these services, so I hope this high-level comment is sufficient to give a picture of the parallel-yet-distinct nature of Flexible and traditional environments. As far as GCE purely considered and Container Engine <https://cloud.google.com/container-engine/>, these are much more toward the traditional web-server model than App Engine is. You're basically provisioning virtual servers which can run web-server software or any other kind of software. Container Engine is a higher level of abstraction than individual VMs which allows you to provision and manage fleets of VMs (not usually that useful for startup apps, but becomes useful with scale). Within a python process on a GCE VM, for example, one can still interface with Cloud Platform / App Engine APIs using Google API client libraries <https://developers.google.com/discovery/libraries> or the Google Cloud client libraries <https://cloud.google.com/sdk/cloud-client-libraries> more specifically, but the autoscaler, versioning, etc. of App Engine are not available, although there are Compute Engine parallels, such as the HTTP(S) Load Balancer <https://cloud.google.com/compute/docs/load-balancing/http/>. I hope this has been helpful, let me know if you have any further questions! Cheers, Nick Cloud Platform Community Support On Wednesday, May 11, 2016 at 9:03:45 PM UTC-4, ingo wrote: > > Hey Nick, > > thanks for your response! I will give your "runtime: custom" suggestion a > try to see if I can stay fully within GAE. > > Some comments: > > - I tried to avoid installing additional dependencies into the app's > Docker container. This might be acceptable for a single additional > dependency. But it mixes concerns and won't scale for larger numbers of > dependencies. > - You are saying my app runs on GCE already. I can see how that is the > case for the instances themselves. But GAE comes with a few features GCE > does not have built-in AFAIK: built-in load balancer, versions, traffic > splitting, per-version domain names, direct access to the datastore and > memcache, Cloud Debugger/Tracer, log aggregation. What of those things > would I loose when migrating my example app from GAE to plain GCE? > - How does this problem relate to Google Container Engine? Does this > sound like a good use case for Container Engine to you? > > > Thanks, > Ingo > > On Wednesday, May 11, 2016 at 10:56:44 AM UTC-7, Nick (Cloud Platform > Support) wrote: >> >> Hey Ingo, >> >> The Flexible Environment (from this point forward, "Flex") is a kind of >> bridge between App Engine and Compute Engine. Flex apps run within a Docker >> container on a Compute Engine instance or pool of instances, and requests >> to the app via appspot.com are load-balanced to go to any one of these >> instances (depending on your scaling settings, the pool's size and growth >> behaviour will be dependent). >> >> Basically, our SDK (gcloud <https://cloud.google.com/sdk/gcloud/>) >> allows you to specificy either "vm: true" (in the case of "runtime: >> go/python27/java/php55/etc.") or "runtime: custom >> <https://cloud.google.com/appengine/docs/flexible/custom-runtimes/configuring-your-app-with-app-yaml#general>" >> >> in your app.yaml or appengine-web.xml (for java) config file. >> >> In the case of "vm: true", your traditional App Engine app will be >> deployed using a special compatibility runtime to a Flex environment, and >> in the case of "runtime: custom", the Dockerfile in your app's root >> directory will be used to build the image of the resulting container which >> is deployed to the Flex Environment (you would need to specify the base >> image using the Dockerfile FROM directive, and ensure a web server process >> is started and listening on the appropriate port). >> >> So, your Flex app is already running on Compute Engine. Therefore, you >> could use "runtime: custom", along with the appropriate go compatibility >> base >> image >> <https://cloud.google.com/appengine/docs/flexible/custom-runtimes/build#base_images>, >> >> and simply specify the install / configuration instructions for statsd in >> your Dockerfile. Each instance of your application would have an installed >> and running copy of statsd, in that case. Although you may also want to >> simply deploy a Compute Engine instance running statsd which is reachable >> via its internal network IP from your app runtime instances, since that >> appears to be more in line with how statsd is meant to be deployed, as a >> standalone service within your network. >> >> Does this help answer your questions? Let me know if anything is unclear >> or remaining to be discussed. >> >> Cheers! >> >> Nick >> Cloud Platform Community Support >> >> On Tuesday, May 10, 2016 at 10:55:27 PM UTC-4, ingo wrote: >>> >>> I built a small Golang app <https://github.com/ingojaeckel/weather-wear> >>> and deployed it to GAE's Flexible Environment. Right now this will create a >>> single Golang Docker container remotely at deploy time. For simple projects >>> similar to this one what is the best practice to add more dependencies that >>> run alongside the app (like statsd)? I want to continue to run my app in a >>> container on GAE. But I want to run publicly hosted Docker images alongside >>> it (e.g. this one <https://hub.docker.com/r/datadog/docker-dd-agent/>). >>> I am looking for a way to run those multi-Docker instances still within GAE >>> to take advantage of high level of abstraction. And if possible I want to >>> avoid having to integrate with a Docker Registry. >>> >>> >>> Is this feasible on GAE or do I have to switch over to Google Compute >>> Engine <https://cloud.google.com/compute/docs/containers/container_vms> >>> or Google Container Engine <https://cloud.google.com/container-engine/>? >>> >>> >>> Thanks! >>> >> -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at https://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/9bc4b27d-5755-4735-bb20-09c5d976f114%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
