HiveBrain v1.2.0
Get Started
← Back to all entries
snippetdockerMinor

How to implement Continuous Deployment in Angular, PHP API and Ansible projects?

Submitted by: @import:stackexchange-devops··
0
Viewed 0 times
ansibleprojectsimplementphpangularhowandapideploymentcontinuous

Problem

I am working on an Angular2 project with Yii2 (PHP/MySQL) as its API point. We will need to deploy the Angular app in different languages for different customers (using AOT compilation from angular-cli).

What is the best way to achieve this? I am looking at Docker or Ansible(-container) to make this work. But the examples are mainly for a 1:1 setup. But I would need a 1:n, something like:

deploy app-de new_costomer prod_server

Additional to that, when a new version of the app is available i want to update the entire network with the new app (that requires uploading of the src/ folder AOT compiled, and db migration scripts on the Yii2 side).

Ideally it would do something like:

deploy update network-all prod_server

Any ideas?

To clarify: I have a number of customers, each customer should get its own container (docker, through ansible-container). There is the AOT compiled Angular stuff (just JS) and the PHP backend with MySQL.

Each customer gets this setup on a server (so 3 customers = 3 docker containers with the Angular + PHP + MySQL).

We push updates to both Angular and PHP quite frequently (i.e. the entire DIST folder needs to be uploaded or at least a diff, migrations scripts for the PHP/MySQL backend needs to run, etc.).

And this from one command (because I obviously do not want to have SSH into each container to do all that semi-manually).

Since I have never done this kind of setup before, I would like to get some ideas on how this can achieved with things like Ansible (or the like).

Solution

Let's assume you have the following scenario: You have many customers, but most use the exact same app, except for some configuration changes. You would like each of your customer to get the latest of the app ASAP.

If this is your scenario then try make everything that needs to be differentiated between the apps a configuration change. You build one (or one set of) docker containers that can handle any of your customer based on the configuration it was given. Then on deployment time you simply supply the proper configurations for this container for each of your customer.

The benefit of this approach is that you don't really incur massive overheads when a new customer comes. You generate their configuration, create the new servers, add some entries into an inventory file, and the next time you deploy, it gets there as well. The more well your CD pipeline is set up the more you can automate any of this process.

So how would the flow generally look like:

  • You have your application codebase, that can cater for all of your customers



  • You build the docker container for your application (one for the frontend, one for the backend, possibly a few more supporting ones)



  • You have a deployment script that uses a configuration file to determine where to deploy and what.



  • You run this deployment script. It will go over all of your customers, and simply deploy the latest version of your app with the appropriate config.



If you have a new customer, the only place you have to change is the deployment configuration file. If you are using ansible most likely you have to change your inventory and your vars file. Let's say you have get a new customer, who would like the app to run under Spanish locale, and has access to the beta features. This customer's configuration would maybe look like this:

config.js:

SETTINGS = { locale: 'es', beta: true };

config.php:

define('CUSTOMER_LOCALE','es');
define('CUSTOMER_BETA','true');


You then make sure that during deployment your container gets these files mounted on startup.

Code Snippets

config.js:

SETTINGS = { locale: 'es', beta: true };

config.php:

define('CUSTOMER_LOCALE','es');
define('CUSTOMER_BETA','true');

Context

StackExchange DevOps Q#226, answer score: 7

Revisions (0)

No revisions yet.