📜 ⬆️ ⬇️

Deploy Drupal 8 with Otto

This post was the result of my acquaintance with Otto, one of the latest products of Hashicorp, which was already a review article on Habré.

My post is more practical. I decided to raise a standard project on otto in order not to immediately stumble upon the subtleties of customization, and in order to be interested, I chose Drupal 8, which was released recently.

image

Installation


The latest version tagged is 0.1.2 from 10/20/2015. Looking ahead, I’ll say that I didn’t manage to set up MySQL on it right away, and also, looking in CHANGELOG, I decided to try the master branch because of Layered Dev Environments.
')
Otto 0.1.3-dev requires Vagrant 1.7.99+, since the stable version is 1.7.4, which means that Vagrant is also needed from the master branch . UPD: Vagrant 1.8 is out, Vagrant is no longer needed.

The compilation of both projects is well described on the otto and vagrant pages , it took me half an hour to install golang, configure gopath and compile both projects without the knowledge of Go and Ruby.
The main thing is not to add
export PATH="$GOPATH/bin:$PATH" 

Restart the terminal, check that we are running the dev version: 'vagrant version', 'otto version'.

NFS configuration
Directly to otto does not apply, but, having learned about the terrible stagnation of standard virualbox shared folders, I realized the need to configure NFS.

On Ubuntu, it is enough to install the nfs-common nfs-kernel-server packages and add a few lines to / etc / sudoers so that Vagrant does not ask for a password every time it is started, for more details see the documentation .


Project preparation


Download Drupal 8:
 git clone https://github.com/drupal/drupal.git drupal8 cd drupal8 

Appfile


Appfile - the main otto configuration file for the project, must be at the root of the project.

In general, it may not be at all, then otto will determine the requirements for the environment in which the application can run. The logic of determining the type of application is nowhere simpler, for example, a project will be defined as php if there are * .php files in the root

otto compile


The first command that is needed in otto is ' otto compile '. It analyzes the project and its Appfile, and then generates a tree in the .otto folder, containing all the information about the dev and deploy configurations of the environments.

Documentation advises not to edit the contents of this folder. But you can and should look.

It will also generate .ottoid - a unique identifier of your application, by which otto will track its deployment, store history, use it as a dependency, etc.

At this point, our environment is described and ready for deployment.

otto dev


The next thing you need is to deploy a local dev environment on the local machine.
In essence, otto dev is the same as vagrant up.

Layered Dev Environments

The concept of layers is interesting, they are very similar to Docker layers: when you first launch otto dev, the Vagrant virtual environment will be configured sequentially, taking a snapshot after each step. Layers are described in application type. All this allows to significantly reduce the time of creation of the dev environment. Thus, we get an instant launch of the finished environment, even with the full re-creation of the virtual machine. The difference between restarting and re-creating the machine ('otto dev halt && time otto dev' and 'otto dev destroy && time otto dev') is about 5 seconds.

Judging by the changelog, vagrant will not get this functionality, at least in the next version, but in Vagrant there will be a functionality for creating snapshots.

You can view the layers with the command 'otto dev layers':
 $ otto dev layers consul php5.6 

As a result, in the case of a PHP application, otto should issue further instructions:
 $ otto dev IP address: 100.66.143.21 A development environment has been created for writing a PHP app. You can access the environment from this machine using the IP address above. For example, if you start your app with 'php -S 0.0.0.0:5000', then you can access it using the above IP at port 5000. 


What have we got with auto setup?

Drupal is critically short of MySQL.

Depencies


The easiest way to add MySQL is to specify a dependency. Create an Appfile in the project root:
 application { name = "drupal8" type = "php" dependency { source = "github.com/hashicorp/otto/examples/mysql" } } 

This config explicitly indicates the type of application (php) and adds MySQL as a dependency.
Despite the fact that the link in the source is invalid, otto will understand it, there are other source formats .

There is a way to add mysql even easier, but it is wrong, I will say about it in flaws.

Appfile mysql describes a dependent application as a Docker container, the path to the container image and launch parameters. As a result, we will get the running container inside Vagrant, thanks to Consul it will be available at the address mysql.service.consul (inside the virtual machine) with the user and root password: root. The default Consul makes it much easier to use Docker, you can not understand the intricacies of setting service discovery, but simply use it.

A dependency can be any other application, but it is strongly recommended that it have a .ottoid file that will allow otto to understand what it is running, even if the application is renamed.

Dependencies at the moment do not support versioning (they promise to add in the future), which means that with every 'otto compile' you have a chance to get not what you expected, so you should fork dependencies yourself or put it on a local machine.

Making 'otto compile', 'otto dev destroy', 'otto dev' - we get a machine ready to launch Drupal. It remains to run the server in it.

otto dev ssh


We come in virtualka on SSH. We execute the above command to start the PHP-embedded web server; I see nothing wrong with running as root on port 80 on dev:
 sudo php -S 0.0.0.0:80 

After that, you can go to the browser to open the IP address that issued the 'otto dev', you can get it explicitly by executing the 'otto dev address'.

disadvantages


Raw code

It can be seen that the code is rather prototypical in some places. For example, in Vagrantfile bash is used to expand the environment, and not ansible or something similar.

I looked into the App type php code, found there a definition that the application being started is wordpress (by the presence of the wp-config.php file), the only difference from the standard php application is the automatic addition of mysql depending. That is, you can now specify in Appfile 'type = "wordpress"' or make 'touch wp-config.php' to get mysql, but, of course, this is not worth doing.

Environment not worked

Judging by the issue tracker of the project, the best practices are not yet ready and it is not entirely clear how they will be prepared. For example, in the case of PHP, there are Hashicorp, which do not know the features of the environment of PHP projects and PHP programmers who do not know Go and cannot send a pull request.

Mitchell Hashimoto, the author of Otto, offers everyone interested to write on Github suggestions with improvements, links to articles with setting the right environment, and Hashicorp will take care of their integration into the product. It seems to me that abstractions will appear later, which will enable a wide range of non-go programmers to help in product development.

Dev is different from prod

I did not get to the 'otto infra' and 'otto deploy' commands, but I learned that now they only support AWS and that for php projects the dev environment is different from the deploy environment, in the first case it is suggested to run the server built into PHP, in the second rises apache2 with mod-php.

Dev poorly customizable

Otto at the moment does not allow customizing Vagrantfile dev-environments through Appfile. We are looking at .otto / compiled / app / dev / Vagrantfile, it turns out that it contains / vagrant mount options incompatible with NFS. We fix the line with something like:
 config.vm.synced_folder '/home/popstas/projects/site/drupal8', "/vagrant", type: "nfs" 

The following 'otto compile' will overwrite these changes.

The only way to do this is to completely redefine the Vagrantfile using application type = “custom”, but in this case all the magic of the environment auto-tuning disappears.

findings


I made a conclusion for myself that Otto is not yet ready for full use, as the product version 0.1 suggests in general. Nevertheless, the product is very interesting and already has advantages over Vagrant, and all the disadvantages are explained by the novelty of Otto, the developers know about them and have plans to eliminate.

Now it is not clear how to create your layers, when the layers will appear in Otto fully, for me it will be enough reason to switch to it from Vagrant.

Source: https://habr.com/ru/post/273009/


All Articles