Going Live
Going Live¶
Tip
The order of operations is not really important, but if you are migrating a project from another provider, you should first configure domains on the SymfonyCloud side, and only then switch DNS over.
1. Production plan¶
First, check via project:info
that your project is not on the development
plan, as domains can only be attached to production plans:
1 2 3 4 5 6 7 8 9 10 | $ symfony project:info
Project ID: nq3xa5jtywvyc
Project title: Symfony Documentation
Status: ok provisioned
Owner: [email protected]
Region: Europe (West)
Plan: Development
Environments: 95/255 actives
Storage: 5 Gb
Users: 6/6
|
To move to a production plan, use the project:scale
command:
1 2 3 4 5 6 7 8 9 10 11 12 13 | $ symfony project:scale
Scaling from Development to Standard...
CPU dev -> 1
Memory dev -> 0.8GB
Apps dev -> 3 (including workers and services)
WARNING You are going to be charged for scaling up the project.
Your credit card will be charged at the end of each month.
Do you confirm? [Y/n] Y
Project updated
|
2. Setup a domain¶
Attach a domain to your project via domain:attach
to allow SymfonyCloud edge
layer to route requests to the project for a specific domain:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | $ symfony domain:attach example.com
Waiting for activity 22jdotpwtrxz6 (Tugdual Saunier added domain example.com):
Building application 'app' (runtime type: php:7.3, tree: a4a225e)
Reusing existing build for this tree ID
Provisioning certificates
(Next refresh will be at 2019-05-28 11:39:30+00:00.)
Environment certificates
- certificate 84c845e: expiring on 2019-06-25 11:39:30+00:00, covering example.com
Re-deploying environment nq3xa5jtywvyc-master-7rqtwti
Activity 22jdotpwtrxz6 succeeded
The domain example.com has been attached.
|
Tip
Multiple domains can be attached to a project. Wildcard Routes (like
*.example.com
) are also supported using the .symfony/routes.yaml
file.
If you require access to the project before the domain name switch is done, you
can create a hosts
file entry on your computer and point it directly to one
SymfonyCloud IP. To get SymfonyCloud IP addresses, run
symfony account:ips --ingress
.
On macOS and Linux, you can add that IP to your /etc/hosts
file. On Windows
the file is named c:\Windows\System32\Drivers\etc\hosts
. You will need to be
an admin user to be able to modify that file. After adding the line the file will
look something like:
1 2 3 4 5 6 7 8 9 10 11 | ##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
52.49.93.188 example.com
|
Caution
Remember to remove this entry after you switched DNS.
3. HTTPS¶
On SymfonyCloud, all environments support both HTTP and HTTPS.
If you don't bring your own certificates, SymfonyCloud provisions certificates using Let's Encrypt. Note that this setup requires that the DNS switch step is completed first.
Note
It can take a couple of minutes for Let's Encrypt to provision the initial certificates. This is expected, and implies that the first deployment after attaching a domain may take longer than usual.
Alternatively, you can bring your own certificates. This is particularly useful when switching over to SymfonyCloud as this avoids any interruption in HTTPS serving.
Caution
When using wildcard domains, SymfonyCloud can not provision certificates on your behalf. You have to provision it on your end and upload them to SymfonyCloud.
4. Switch DNS¶
Configure your DNS provider to point the project domain(s) to SymfonyCloud.
The precise way to do so varies depending on your registrar, but nearly all registrars should allow you to set a CNAME. Some might call it "Alias" or similar alternate names:
- Obtain the CNAME target by running
symfony cname
; - Add a CNAME record for your desired domain (
www.example.com
) using the value obtained before.
Note
Depending on your registrar and the TTL you set, it could take anywhere from 15 minutes to 72 hours for the DNS change to fully propagate across the Internet.
APEX¶
SymfonyCloud expects you to use a CNAME for all DNS records but CNAME don't work with APEX domains.
Depending on your project constraints, several options are available:
Using a DNS provider with custom type records¶
Some DNS providers have found a way around the CNAME-on-Apex limitation by doing their own internal lookup behind the scenes:
- CNAME Flattening at CloudFlare
- ANAME at easyDNS
- ANAME at DNS Made Easy
- ANAME at Name.com
- ALIAS at DNSimple
Tip
We recommend that you check support for dynamic APEX domains before registering your domain name with a DNS Provider.
Using a DNS provider with APEX domain forwarding¶
If you are willing to make the www.
version of your project the canonical
version, some registrars or DNS providers may provide a domain redirect feature.
The following DNS providers are known to support both APEX forwarding and
advanced DNS configurations simultaneously:
Using a www redirection service¶
If your preferred registrar/DNS provider doesn't support either custom records
or the APEX domain forwarding options above, the following free services both
allow blind redirects and allow you to use a CNAME record to SymfonyCloud
for www.example.com
and an A record to their service at example.com
,
which will in turn send a redirect.
Using A records¶
If you cannot use a DNS provider that supports aliases or a redirection service, it is possible to use A records.
This process has a few limitations:
- Should SymfonyCloud ever need to change one of its IPs, your configuration will need to be manually updated (some requests will be lost in the meantime).
- Using an IP means that your requests will be directly pointing at a SymfonyCloud router, bypassing their load-balancing functionality. Should one of them go offline for maintenance (as happens periodically for upgrades), approximately 1/3 of requests will go to the offline router and be lost, making the project appear offline.
Using A records is strongly discouraged and should only be used as a
last resort. You can get SymfonyCloud public IPs via
symfony account:ips --ingress
.
5. Bonuses¶
The following steps are not required but good practices when going live with a SymfonyCloud project.
Scaling¶
With SymfonyCloud, you get a set of resources according to the project monthly
plan. When those resources are being exhausted by a peak in the traffic, a
project can be scaled up in a matter of seconds with symfony project:scale
.
Once the peak of traffic is done, scale down with symfony project:scale
--down
. At the end of the billing period, the project invoice will include a
pro-ration for the period where the project was on a higher plan.
Automatic snapshots and certificate renewal¶
It's strongly recommended that you set up automatic snapshots and automatic certificate deployment cron tasks. You will first need to set up an API token and set it up in your project environment variables. Then you can easily configure the appropriate cron tasks. The following snippet is generally sufficient but see the links above for more details, and please modify the cron schedules listed to match your use case.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | crons:
snapshot:
# Take a snapshot automatically every night at 3 am (UTC).
spec: '0 3 * * *'
cmd: |
if [ "$SYMFONY_BRANCH" = master ]; then
croncape symfony env:snapshot:create --no-wait
fi
renewcert:
# Force a redeploy at 8 am (UTC) on the 14th and 28th of every month.
spec: '0 8 14,28 * *'
cmd: |
if [ "$SYMFONY_BRANCH" = master ]; then
croncape symfony env:redeploy --no-wait
fi
|
Health checks¶
While not required, it is recommended that you set up health notifications to let you know if your project is experiencing issues such as running low on disk space. Notifications can be sent via email, Slack, or PagerDuty:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | $ symfony integration:add
Please select the type of integration you want to add:
[0] github
[1] gitlab
[2] health.email
[3] health.pagerduty
[4] health.slack
[5] hipchat
[6] webhook
> 2
From (email): [email protected]
Recipients: [email protected]
Created integration efelccbyabjdi (type: health.email).
┌──────────────┬────────────────────┐
│ Property │ Value │
├──────────────┼────────────────────┤
│ from_address │ [email protected] │
│ id │ efelccbyabjdi │
│ recipients │ - [email protected] │
│ type │ health.email │
└──────────────┴────────────────────┘
|
Monitoring¶
While not required nor integrated, we recommend you to set up external monitoring.
CDN¶
While not required nor integrated, you can set up a CDN in front of your project. CDNs let you cache public pages and assets at the edge making your websites load faster.
This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.