Ah thanks for the explanation, it helped me figure out what was wrong on my end.

And sounds good, I'll open issues that I come across, thanks.

@tieujason330 Make sure your ElasticSearch template is a nested stack on the tenant-onboarding-app.yaml stack, not on the tenant-onboarding.yaml stack.

Looks like a bug that the Lambda for the tenant event handler function is not named the same as the rest of the tenant microservice functions. I'll get a fix in for that and then the update_service.sh script should work as intended.

@brtrvn is there a particular reason why ElasticSearch should be a nested stack in the apps stack? I nested it within tenant-onboarding.yaml since I wanted to pass along elasticsearch info to all my containers (they all rely on Elasticsearch in some way). I was able to do this by storing relevant ElasticSearch info in the attributes map when updating the tenant on the stack CREATE_COMPLETE event. Feel free to let me know if there could be a better way of handling this, thanks!

Currently, the isolation model of SaaS Boost is silo based isolation -- meaning every tenant would get their own ElasticSearch cluster. I think you are aware of this, just restating it.

When we extended SaaS Boost to support multiple compute environments (aka services), they are treated as separate entities -- just as you'd expect in a micro services design. So, if Service A has a database, then Service B shouldn't have access to that database other than through the API contract of Service A.

You can certainly craft a solution to get around this -- as you're doing -- but you're running into errors and challenges because SaaS Boost isn't designed to work this way.

As designed, I'd suggest that you have an internal service that fronts ES and your other containers delegate ES work to that internal service's API to support features backed by your ES cluster.

Thanks for the insight, I'll review how I integrated ES and aim to fit the micro services design to keep things consistent.

Hi @feiszli , thanks for looking at SaaS Boost! Glad to hear you're excited to try working with our multi-container offering. I'll take a shot at answering your questions:

1. At the moment docker-compose is not usable alongside SaaS Boost. SaaS Boost and docker-compose solve a similar problem: both provide a way to define your application into multiple services and eventually deploy it to AWS, but only SaaS Boost offers the SaaS-specific services as part of the same offering. We are already aware internally that some customers may want to install their own application their own way, and are working to see how we can redefine SaaS Boost to provide for that.
2. You're right, currently we only support one exposed port per container.
3. You are correct, currently services are restricted to http/https. While the ECS exposed ports are listening on TCP in SaaS Boost, with the only other option being UDP, the Application Load Balancer only allows for ingress on ports 80 and 443.

Don't let this stop you from giving it a shot, however! Your feedback is always incredibly useful and any more opportunities you have to kick the tires are appreciated.

Additional thoughts:

The Docker Compose docker-compose.yml file is essentially replaced by the application config file in SaaS Boost. You can see what your app config looks like by issuing a GET against your public API instance /settings/config resource. We give you a user-friendly UI to create the app config, but you can certainly craft your own JSON and PUT it against /settings/config. Of course, it must be in a valid form that SaaS Boost understands.

Please submit a feature request to the Issues list for multiple port support and explain your use case so we can think through it. Adding multiple port support is pretty straight-forward from a docker standpoint. The hard part is going to be how that maps to the load balancer. As PoeppingT pointed out, the ALB only works with HTTP/S ports. If these other ports are used for internal features to support additional services in your application, you could deploy them as non-public services in SaaS Boost.

You shouldn't be limited to HTTP/S for "private" services. At runtime, your services will have environment variables set for each of the private services you defined in SaaS Boost following a naming convention of SERVICE_${SERVICE_NAME}_HOST and SERVICE_${SERVICE_NAME}_PORT How you choose to interact with that host over that TCP port is up to your code. So called private services are not fronted by an ALB, but they are load balanced by ECS Service Discovery.

Yes @tieujason330 (#74) should be fixed by dbb7804. Are you using the latest version of the multi-container branch?

thanks, i see that it's looking for the comment specifically being <domain> Public DNS zone. so does that mean it'll only officially support re-using existing Hosted Zones created by saas-boost? i can manually update my other hosted zone (created by Route53 Registrar) to match that pattern but it'd be nice to be able to specify it somehow. it's not a big deal though

That's a good callout. Please create a bug against the repository with a description of the problem and your suggested solution so we can track this bug report.

Hi Team, I am getting the below error while trying to install using v2.0.0-rc1 -

Installation Error: Error with CloudFormation stack sb-devrc2. Check the events in the AWS CloudFormation Console

Any pointers? @PoeppingT

Hey @vikasagaws , to give you direct advice we would need to know what went wrong, which you can find by looking into the failure events for your base stack (titled sb-devrc2 in this case) in your CloudFormation console. By scrolling down you should see each resource owned by the CloudFormation stack and all their state changes. There will be one with red text describing failure, and it may be a child stack!

@kaypee90 multi container support has been available for over a year. Please use the latest release and you can follow the getting started guide for instructions.