Develatio’s Yii AMI will let you deploy a full Yii project in less than a minute and with zero configuration, enabling you to focus on what’s really important: your own code!
This AMI is provisioned with several core components, configured for production usage.
Aside from easy deployments, security is another topic that we’re really concerned about. That’s why this AMI is also provisioned with some extra components that will let you secure, prevent and monitor your EC2 instance for attacks, intrusions, FS modification attempts, etc…
The AMI is designed in such a way that you only need to deal with one folder: /var/www/webapp
. In that folder you’ll have all your configurations and your source code.
This is how the AMI will look like when you launch it:
├── conf
│ ├── autorun.sh
│ ├── cron
│ │ ├── d
│ │ ├── daily
│ │ ├── hourly
│ │ ├── monthly
│ │ └── weekly
│ ├── global
│ │ ├── hostname
│ │ └── timezone
│ ├── mail
│ │ ├── msmtprc
│ │ └── notifications
│ ├── netdata
│ │ └── password
│ ├── nginx
│ │ ├── helloworld.crt
│ │ ├── helloworld.key
│ │ └── web.conf
│ └── php
│ ├── www56.conf
│ ├── www70.conf
│ ├── www71.conf
│ ├── www72.conf
│ ├── www73.conf
│ └── www74.conf
└── src
├── assets
├── codeception.yml
├── commands
├── composer.json
├── composer.lock
├── config
├── controllers
├── mail
├── models
├── requirements.php
├── runtime
├── tests
├── vagrant
├── vendor
├── views
├── web
├── widgets
├── yii
└── yii.bat
You can check the contents of our demo project here
Let’s start with the more obvious part, the src
folder. This is the usual Yii folder structure.
That said, let’s move on to the conf
folder. That folder contains the configuration files for each service. You’ll be able to edit the behavior of all the services from here, without having to edit anything else. Just apply your changes and restart the services using the usual systemd
commands.
Here’s a quick run-trough the basic conf files:
/etc/cron.*
folders structure you’d expect to have. Scripts inside these folders (d
, daily
, hourly
, monthly
, weekly
) will be copied to the corresponding folder in /etc/cron.*
.global/hostname - Sets the hostname. Use any of the available variables:
Keep in mind that the value of the resulting string will be slugified according to RFC 1123, which means that only letters, digits and hyphens are allowed
global/timezone - Sets the timezone. Use whatever you’d normally put in your /etc/timezone
file. Check /usr/share/zoneinfo/
.
mail/msmtprc - You can configure an SMTP server which will be used to send alerts from Auditd, RKHunter, Fail2ban, etc…
mail/notifications - Write a single line containing a valid email address to which the alerts should be sent
netdata/password - This is the file you’ll want to edit in order to change Netdata’s basic auth user/password. Use the usual command to generate a valid NGINX username and hash: openssl passwd -apr1 netdata
. The user/password in the demo AMI is netdata/netdata
nginx/web.conf - This is the NGINX’s website configuration. The default file is configured to reverse proxy everything to one of the PHP-FPM servers. It will listen by default on port 80, but there is a commented section in the configuration that will enable HTTPS using your certificates (nginx/helloworld.crt and nginx/helloworld.key)
php/wwwXY.conf - Those are the PHP-FPM pools configuration files. There is one configuration file per PHP version (www56.conf
belongs to the PHP-FPM 5.6
server, www70.conf
belongs to the PHP-FPM 7.0
server, and so on…). Each server is listening on port 30xy
, meaning, PHP-FPM 5.6
is listening on port 3056
, PHP-FPM 7.0
is listening on port 3070
, and so on… This is important as this is how you switch the PHP version in your application. You point NGINX’s fastcgi_pass
option to the port of the PHP-FPM localhost server you want to use (localhost:3056
for PHP-FPM 5.6
, localhost:3070
for PHP-FPM 7.0
, and so on…).
There are some extra stuff you must know. First of all, let’s start with the one file that hasn’t been covered yet: the autorun.sh
. This script will be executed at every boot, using the admin
user. Keep in mind that the AMI will make read-only the file on every boot, and it will chown it to admin
.
Why is this script useful? You might want to execute some extra tasks after booting. Maybe collect static files or maybe run migrations.
Secondly, there are some commands that you can run at any time in order to apply the changes you’ve made in the configuration files:
/etc/cron.*
folders and then moves a fresh copy of the user-provided scripts, as described in the description of the cron/ folderglobal/hostname
(in /var/www/webapp/conf/
)conf/mail/notifications
(in /var/www/webapp/conf/
)global/timezone
(in /var/www/webapp/conf/
)This AMI has two systemd services that will run unattended updates: apt-daily.service and apt-daily.timer. If you don’t want to automatically
keep your system updated, feel free to disable those services using the usual systemd commands (systemctl stop | disable
).
We strongly recommend to set proper permission to your conf
and your src
folders. We set the following permissions in our base AMI.
chown root:root /var/www/webapp
setfacl -R -d -m u:admin:rwx /var/www/webapp
setfacl -R -d -m g:www-data:rx /var/www/webapp
setfacl -R -d -m o::--- /var/www/webapp
setfacl -R -m u:admin:rwx /var/www/webapp
setfacl -R -m g:www-data:rx /var/www/webapp
setfacl -R -m o::--- /var/www/webapp
This will make the files
root
www-data
admin
You’ll probably want to set write permissions to some folders (files uploaded by users?). We recommend using the autorun.sh
.
Keep in mind that the autorun.sh
will be ran with the admin
user, so you’ll need to use sudo
.
sudo setfacl -R -d -m u:admin:rwx /var/www/webapp/src/user_uploads/
sudo setfacl -R -d -m g:www-data:rwx /var/www/webapp/src/user_uploads/
sudo setfacl -R -d -m o::--- /var/www/webapp/src/user_uploads/
sudo setfacl -R -m u:admin:rwx /var/www/webapp/src/user_uploads/
sudo setfacl -R -m g:www-data:rwx /var/www/webapp/src/user_uploads/
sudo setfacl -R -m o::--- /var/www/webapp/src/user_uploads/
The AMI provides the following systemd services, which you can use using the usual commands (systemctl status | start | stop
) in order to manage your application:
php5.6-fpm
, php7.0-fom
, php7.1-fpm
, and so on…) (NGINX will reverse proxy to this server)In case of failure or unexpected errors, use journalctl -f -u <service>
to monitor the services.
We recommend to use Packer and this AMI as a base image to build your own AMIs right from your CI/CD pipeline. Use the provisioners
section in your Packer script in order to copy your configuration files to the conf
folder and your source code to the src
folder. You might also want to run any additional scripts or commands that don’t require the project to be running, for example, package managers install process (npm
, composer
, pip
, etc…).
Modify the files in the src/config/
folder in order to setup your application.
v0.1.0 - 24/10/2019