How to move to production / change region with copilot?

[gtamas]

@efekarakus

Our app is soon to be deployed to production. It's an ECS app which consists of 7 Backend services and 3 Load Balanced Web Services.

Currently the app exists in the Bahrain region, but many AWS services (most importantly CodeDeploy) are not available here. So we have decided to move the app to a different region. Question is, how should we do this? My understanding is that we have to do the following:

• Create another app in the new region
• Create the app using the --domain flag, so we can specify our domain name
• Create test and prod environments.
• Deploy our backend / web services using the new app (--app flag)

Is this correct?

I'm not sure how to handle the prod deployment with copilot.

• Copilot will create URLs like https://{service}.{env}.{app}.mydomain.com. This is fine for testing, but what about prod?
  We want to use the following URLs in production:

https://admin.domain.com (web service, admin frontend)
https://api.domain.com (another web service, reverse proxy)
http(s)://www.domain.com and http(s)://domain.com (web service, main app frontend)

How can I achieve this? Should I follow the steps you described here?
#2071

• What about the feature you mentioned:

http:
  alias: api.mydomain.com

Is this available or not yet?

• In order to be able to use CodeDeploy and other services, the app created with copilot will be located in the eu-west-1 region. However, we would like to keep the rest (backend services, web services) in Bahrain region. How can I deploy a service to a specific region? I can't see any flags for this in copilot.

Please help us with these questions.

Thanks advance!

[efekarakus]

Hi @gtamas

Is this correct?

That's correct! The steps you outlined will get you there.
Alternatively, if you'd like you can still keep the existing application and run copilot env init to create new environments test-eu, and prod-eu in the different region and then copilot deploy to those region. Afterwards, you can remove the existing environments in Bahrain.
If you're using a CodePipeline you can modify the deployment stages to point to the new environments:

stages:
- name: test-eu
- name: prod-eu

 http:
 alias: api.mydomain.com

Is this available or not yet?

Very soon! In the mean time if this is urgent, this comment: #1188 (comment) describes how to take manual steps for it.
We're currently working on the last pull-request for it: #2320 and then the feature will be shipped 😄.

How can I deploy a service to a specific region? I can't see any flags for this in copilot.

Services get deployed to environments. With Copilot you can run copilot app init --domain using the AWS profile that points to eu-west-1, and then run copilot env init using profiles that point to Bahrain. This way when you deploy your service, either manually or through a pipeline, the service will be deployed in Bahrain.

However, I am not sure how CodeDeploy is used with your application and I wonder if having your CodeDeploy resources in eu-west-1 trying to interact with services in me-south-1 will cause problems. I'd suggest trying to keep all your resources in an environment within the same region. An alternative might be to create your application in me-south-1, and then your environments in eu-west-1.

Hope this helps!

[gtamas]

@efekarakus
Thanks for the detailed info again! It's very useful, I'll try to do it this way.
However, it's still not clear to me what needs to be done regarding the web service URLs.

So if I want to customise the URL generated by copilot, should I follow:

#1188 (comment)

or

#2071

I mean, these are different instructions regarding the URL. Our domain is not managed by Amazon (Route 53), we use Godaddy.

Regarding regions:

"An alternative might be to create your application in me-south-1, and then your environments in eu-west-1"

In this case all the services would be deployed in eu-west-1, right? CodeDeploy is available there, so that would work, but our users are in me-south-1, so network operations wouldn't be very efficient, I guess. In general, network ops would be slower (for the users)., correct?

Anyway, so as long as all the services and CodeDeploy resources are in the same region, it's guaranteed to work, but keeping CodeDeploy (and other) resources in one region and services / environments in another wouldn't work. So basically, we should put all our envs and services to eu-west-1 as well, right?. If we do this, then what's the benefit of creating the app in a different region?

Sorry about the confusion :) These things are still not totally clear to me.

[gtamas]

@efekarakus
Anyway, thanks again for the info. The domain name part is clear now.

But I'm not sure about CodeDeploy. I mean, are you sure placing only the CodeDeploy resources to eu-west-1 and keeping everything else in Bahrain wouldn't work?

We also use CodeArtifact. This is also not available in Bahrain. So we created the resource in eu-west-1 and it works like a charm, even though all our services are still in Bahrain (we use it as private NPM registry).

So maybe CodeDeploy could work too?

If we have to move our services where CodeDeploy is then we would probably not use this service. Automated deployments would be nice, but the network latency would be bad for our users.

Thanks in advance!

[gtamas]

@efekarakus
I tried to follow your suggestion and execute the following using a profile pointing to eu-west-1

copilot app init --domain mydomain.com 

However copilot prints this:

no hosted zone found for mydomain.com

Does this mean that we have to move the domain from Godaddy to Amazon? So only domains registered in Route 53 are supported, right?

I assume then the suggestion about deploy URL customisation (#1188 (comment)) also only works with Amazon Route 53, right?

Lastly, CodeDeploy: If I set this up in eu-west-1, then it's not guaranteed to work as long as our environments are in me-south-1. If I move the environments then it'll work fine, but then the services will run in eu-west-1. Correct?
So there is basically no way to use CodeDeploy AND run the deployed services in Bahrain, is that right?

Please get back to me regarding this. I would like to clarify everything asap, since we need to know what to do exactly in order to move the app to prod.

Thanks in advance!

[efekarakus]

Does this mean that we have to move the domain from Godaddy to Amazon? So only domains registered in Route 53 are supported, right?

Correct, the domain has to be registered with Route53. Otherwise, Copilot cannot modify the records for the subdomains.
I wonder if this could help in this situation: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-transfer-to-route-53.html

Does this mean that we have to move the domain from Godaddy to Amazon? So only domains registered in Route 53 are supported, right?

Correct!

If I move the environments then it'll work fine, but then the services will run in eu-west-1. Correct?

Correct!

So there is basically no way to use CodeDeploy AND run the deployed services in Bahrain, is that right?

Yes, I believe so until CodeDeploy is available in Bahrain :( It might be worthwhile prototyping to validate that this is indeed true as I'm not well familiar with CodeDeploy.

[gtamas]

OK thank you again for the clarification. We will move the domain then and won'r use CodeDeploy for now.

[efekarakus]

Thanks! Feel free to create new issues if you run into any problems during the migration!

[gtamas]

@efekarakus
Moving our domain name from the other registrar is delayed by some unexpected permission problems, however we've already moved the DNS service to Route 53. So now we have the domain in Route 53 and we use amazon name servers. Is this not enough for copilot?

I mean, I assume copilot wants to update the DNS records when I use the --domain flag, right? That part is already transferred. Fully transferring our domain name will take some more time, but I wonder, do we really have to wait for that?

Thanks in advance!

[efekarakus]

Hi @gtamas ! I'd recommend just giving it a try first with a dummy application copilot app init -n deletemelater --domain <domain> to see if it's working, and then run copilot app delete -n deletemelater at the end to clean up those resources.
I believe it should work, but I'd recommend building a quick test app first to validate.

[gtamas]

@efekarakus
Thanks, it seems to work!
A question:
I can see that this has beed merged into mainline

#2320

Does this mean the feature is now available? Should I update copilot? We are using 1.3 currently

[efekarakus]

Yay!! It's not released yet :) you can use the feature if you like by building the binary from mainline running make. However the feature should go out in v1.8.0

[gtamas]

@efekarakus
OK no problem. However changing the domain name manually doesn't work for me. I tried to follow the instructions you recommended (#1188 (comment)), here is what I did so far:

• Created app using the --domain flag
• Created and env (test)
• Deployed a load balanced web service
• Copilot created this url: https://frontend.test.coretailcom.coretail.com

This worked, the service also works fine. Now in order to change the domain I did this:

• Requested ACM certificate for frontend.coretail.com domain. AWS verified this, it's green.
• Bound that certificate to the HTTPS Listener by changing "Default SSL certificate" to point to the new certificate.
• Created an A record in Route53 which points frontend.coretail.com to the public IP address of the ECS service copilot created.

Problems:

• I was not able to add another rule to the HTTPS Listener, as suggested:

"In that same listener add one more rule “send all requests from your.route53.managed.domain to the same target group”
"

This is not possible, because all action types inactive, except for the "Authenticate" action, which is not what I need.

• The frontend.coretail.com address is now recognized, but the browser can't connect.

Please help me with these instructions. What should I change?

[gtamas]

@efekarakus
Just to clarify. My only questions is:

How can I point subdomain.coretail.com to the deployed ECS service? Maybe the instructions regarding customising the domain are not fully up-to-date, I'm not sure.