search

jambonz / jambonz-infrastructure

packer and cloudformation templates for creating EC2-based jambonz deployments
23 stars 29 forks source link

Introduce jambonz-medium #59

Closed eravelo closed 1 year ago

eravelo commented 1 year ago

This is to suggest a third AWS deployment configuration called jambonz-medium . The goal is to limit the number of instances involved while making the version upgrades easier by sharing the database. It is derived from jambonz-mini with the following changes:

This is the related PR: https://github.com/jambonz/jambonz-infrastructure/pull/58

davehorton commented 1 year ago

can you clairfy the number of suggested autoscale groups and their contents @eravelo ?

eravelo commented 1 year ago

@davehorton only one autoscale group that contains : all the services found in the jambonz-mini deployment, except the monitoring server which runs in its own instance. Configuration of the services in the autoscale group were modified to deal with :

davehorton commented 1 year ago

I do agree that a "medium" AWS autoscale configuration could be useful, but IMO I would not configure it like that.

The problem is that each of these 3 elements scale very differently

By putting them in the same autoscale group you would, for instance, be popping out another EIP for a SBC SIP server whenever the FS needed to scale. And that is actually problematic - since your public SIP IP addresses need to be shared with your partners and SIP providers, you really don't want them coming and going all the time.

For comparison, the jambonz "large" deployment is defined here, and includes separate autoscale groups for SIP, RTP, FS, and Webserver. That is kind of a fully scaled out system.

My thoughts on what a good "medium" configuration would be

or, the last could be replaced with

Either way, there needs to be a single monitoring server because it includes databases (influx, postgresql, cassandra) which there can only be one of.

I'll note that as of release 0.8.4 the load on the webserver could be significantly higher due to the new recording feature which directs audio streams to jambobz-api-server for upload to S3 so either the web server may need to run on a sufficiently beefy instance or be in an autoscale group. For a "medium" deployment I would think a single webserver on a suitable instance (c6i or something) should be fine

eravelo commented 1 year ago

Thank you @davehorton for the insightful comments. I will update the jambonz-medium branch accordingly.

davehorton commented 1 year ago

I am going to put together a jambonz-medium configuration along the lines of what I suggested above, which will mean creating new packers. This medium will be

eravelo commented 1 year ago

Cool! In the mean time I saw that there is already an old jambonz-sbc-sip-rtp packer directory, which you seem to have deprecated.

eravelo commented 1 year ago

@davehorton, what do you think of my proposal to have an ALB in front of the Webserver to avoid to manually setup the letsencrypt certs?

davehorton commented 1 year ago

@davehorton, what do you think of my proposal to have an ALB in front of the Webserver to avoid to manually setup the letsencrypt certs?

I think as an option it would be useful, but not everyone will choose to use AWS for their DNS and certs and I don't want this to exclude everyone else. I for instance use dnsmadeeasy and lets encrypt and the basic deployment should support that as well. So if the option to deploy an ALB and generate the dns records and certs was enabled via an option in the CF then I think that would be a value add

eravelo commented 1 year ago

Fair enough.

davehorton commented 1 year ago

I've pushed this PR which I am testing that has my vision of a jambonz medium https://github.com/jambonz/jambonz-infrastructure/pull/61

eravelo commented 1 year ago

Closing this issue which is resolved by this PR https://github.com/jambonz/jambonz-infrastructure/pull/61