Provide means to deploy multiple services

[briandealwis]

A message from the google-appengine mailing list requests the ability to deploy multiple services at once. The poster reports this as a blocking issue preventing migration from GPE.

[elharo]

Are you sure that's the right message? I don't see anything there about multiple services.

[briandealwis]

It was the link to the conversation — I've linked to the message now.

[elharo]

The message asks for migration, not deployment, of a mutiservice project.

[briandealwis]

That's not how I read it: the thread is about how deploying is failing. The author notes that deploying with CT4E does work but as we don't offer a way to deploy multiple services, he's staying with GPE. With GPE, a user can deploy multiple modules with an EAR. With CT4E a user must deploy each module/project in turn.

Since we require users to specify the respective service IDs in their appengine-web.xml, and none of the values shown in our deploy dialog only apply to particular services, I think this might be easy to support.

[briandealwis]

(By 'migrating' I think the author means moving from GPE to CT4E. )

[elharo]

We need to figure out what exactly is needed here and design the solution before proceeding. Right now this is too vague.

[nverwer]

Dear Brian and Eliotte,

Thank you both for making this an issue.

I posted the message that you are referring to. I am busy trying to migrate my project from GPE to CT4E. It struck me that deployment using the GPE did not work on December 5th, but deploying one of my CT4E projects was without problems. This is what triggered my remark.

This project contains multiple services/modules, and follows the structure described in chapter 5 of Programming Google App Engine with Java. This means that there is an EAR project that refers to the default project and (in my case) 2 other projects.

Although the project is important for my customer, it is a side project for me, and we are in the process of changing several things in the front-end. Therefore, I am migrating to CT4E slowly and cautiously. I have migrated 2 of the 3 services/modules and they seem to work. Tomorrow I plan to verify this, but I think that migrating the EAR project is unnecessary. There are also quite a few things in my appengine-web.xml files that CT4E says are superfluous now. One thing I need to solve is that 2 of the services projects share code, but that looks like I can solve that.

If it turns out that just migrating the 3 services/modules projects is enough, I would consider this a great step forward from how things work in GPE. The EAR project always seemed a bit strange to me. Being able to deploy the 3 projects independently is much better than deploying everything in one go as in GPE.

I appreciate that the CT4E documentation now also includes instructions for the minority group of Maven-haters that I belong to. I think the idea behind maven is sound, but the way it has been implemented is atrocious.

When I make progress, or run into trouble, I will describe my findings here.

[nverwer]

Here is what I did to migrate my multi-service (multi-module) project:

• Forget about the EAR project. It is no longer needed for the Cloud Tools for Eclipse.
• Migrate each of the service / module projects using these instructions. For each service there will be one Eclipse project and there is no common (EAR) project.
• If you still use Google Cloud Endpoints v1, you are going to do another migration (to v2) soon. For now, the jar files appengine-endpoints.jar and appengine-endpoints-deps.jar must be copied into WebContent/WEB-INF and included in the build path by refreshing the Web App Libraries.
• The targeted runtimes of the Eclipse projects may have to be adjusted.

After this, I followed the other how-to guides, and tried not to think about what could go wrong. Everything seems to work.

In the local development environment, you could add all services (modules) to one server, just like before with the Google Plugin for Eclipse. However, except for the default service, you cannot choose your own port numbers. Therefore, you may want to define a separate server for each service (Eclipse project).

Using Cloud Tools for Eclipse, it is possible to start separate local servers for each service. Also, each service can be deployed separately. This is a major advantage over the old Google Plugin for Eclipse.

When deploying, the log messages will tell you that the appengine-web.xml files must be updated: <application>/<version> XML elements should not be specified. Because there is no common (EAR) project, the application is not needed. Version identifiers are now automatically generated. The App Engine project to which you deploy your service is configured in the App Engine Deployment properties.

[briandealwis]

@nverwer I'm guessing you must have some special-case code for local debugging? The one downside to launching multiple devappservers is that you will hit lock errors should you have multiple services try to use Datastore. Launching multiple services is also a bit of a pain.

One option is to use the App Engine API's ModulesService to get local host:port connection points for your services (aka modules). The full ModulesService API isn't supported, but you can use:

• getCurrentModule()
• getCurrentVersion(): always returns no_version
• getModules(): returns the service IDs
• getVersionHostname(serviceId, "no_version"): returns localhost:XXXX on the local devappserver, and returns the dot-form hostname to reach the service on App Engine (e.g., version.serviceId.projectId.appspot.com)

If you deploy your services with same versions (e.g., blue or green if using a blue-green deployment strategy), using the ModulesService would be really easy since you'd always be accessing service versions that corresponds to the current service's version.

If you deploy using different versions, you must have some kind of service-version table, in which case you could special case the local-run situation to always use no_version.

[nverwer]

@briandealwis Thank you for your response. It is indeed easier to run one server with all three services.

It is easy to get the localhost:port; I only have to look at the logs. However, it would be great if I could set the port, so it always the same. This is possible for the default service, although once that is set it cannot be changed in the run configuration. It would be great if the server would use one port, and I could do the same as on the Google servers and use service.host:port .

Apart from this, the migration from GPE to CT4E was quite easy. What was missing for me was (as I mentioned above) the instruction to remove and forget about the EAR project. Not having that is actually an improvement.

[patflynn]

filed internal b/71497907 to track devappserver support for passing flags to multiple running services.