[ Update: Delivered! ] Fundraiser: Would you help finance a plugin that would allow MUP (Meteor UP) to deploy AWS?

packages
43

Yes, I am interested in doing more work on the plugin. My schedule is currently full, but I could start on it mid to late April.

Are there any specific bugs fixed or features added that you want?

2 Likes
44

Things I think would be nice to do:

  • Review the PRs
  • Elastic beanstalk platform upgrade, automatic? Other changes needed for new elb verison?
  • Deployment times seems really long, can be improved? (probably the biggest issue atm)
1 Like
45

Schedule still busy? :wink:

1 Like
46

Any updates on this @zodern ? :slight_smile:

1 Like
47

I wrote a custom version of this for deploying direct to AWS ELB based servers (including an attempt to auto-config them), it works reliably for the four applications weā€™re using it for, but Iā€™ve not tested it in the larger scheme of things, if anyone is looking for a solution ā€œright nowā€ this might work for them:

https://bitbucket.org/znewsham/mup-aws-elb/src/master/

3 Likes
48

Thanks for the link!, it looks really promising. If this could get up to the features offered by mup-aws-beanstalk i would defintetely give it a try ( sharing load balancers between apps is something that would reduce our costs drastically :slight_smile: )
Any ETA on the ā€œin progressā€ features? Also, I couldnā€™t find the advanced configuration section to see how to share the load balancer

49

Youā€™re right, the ā€œadvancedā€ section is missing - Iā€™ll see if I can dig that up. Here is a nearly complete (missing credentials of course) example:

https://bitbucket.org/znewsham/mup-aws-elb/src/master/docs/example.js

Regarding the features, this has dropped off my radar a little, as it is working as is.

We found a way to do green/blue deploys without really needing to change the MUP process much (you just configure a second mup file to deploy to a different target group, then swap out the target groups).

Re configuring the load balancer partly works, the piece that doesnt is the order of the listeners. If your listener is missing it should add it (been a while since I looked at this), however if it is present but in the wrong place it wont.

Security groups will be added correctly, but wonā€™t be edited (again, this is more than we need at the moment).

Controlling where new instances get put (AZā€™s) kinda works, in that you can specify a set of AZā€™s and the new instances will go in one of them, but its at random. So in theory it is possible to have all your instances spin up in one zone (Iā€™ve not had this, and it only matters when adding new instances, not re-deploying).

50

Iā€™ve tried to follow the example, but not really sure about how to modify the loadbalancer options to make it work with different apps in different domains.
Iā€™ll wait to see if we get any response from zodern, but if not, Iā€™ll try to dig deeper into what things could be done to improve this one for our needs. Thanks again! :slight_smile:

51

You need 1 config per project, Iā€™d actually advise you to configure the load balancer manually through AWS to start with (though if youā€™re not doing this in a production env, feel free to try it direct with mup!

we have 6 apps sharing the same balancer, some based on path some on domain. You configure the load balancer globally, then each of your apps has a mup config file which references the relevant listener. Here is an example of our config for two apps:

      balancer: {
        securityGroups: ["redacted-admin-balancer"],
        name: "balancer-name",
        ssl: {
          certificateArn: "redacted"
        },
        tags: [
          {
            key: "env",
            value: "production"
          },
          {
            key: "app",
            value: "redacted-admin"
          }
        ],
        rules: [
          {
            conditions: [{
              field: "path-pattern",
              value: "/admin/*"
            }],
            priority: "5"
          }
        ]
      },

 balancer: {
        securityGroups: ["redacted-app-balancer"],
        name: "redacted",
        ssl: {
          certificateArn: "redacted"
        },
        tags: [
          {
            key: "env",
            value: "production"
          },
          {
            key: "app",
            value: "redacted-app"
          }
        ],
        rules: [
          {
            conditions: [{
              field: "path-pattern",
              value: "/app/*"
            }],
            priority: "4"
          }
        ]
      },

The priority value indicates the order they should be in in the load balancer (e.g., match /app/* requests before /admin/* - this is more important when you have a mix of domain and path listeners)

3 Likes