-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable deployment of engine
and federation-api
on a single server
#41
Conversation
b4c32ae
to
b35766e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are great changes 👏 and we should to spend some time together so that I can become a little more independent with the deployment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really good changelog, congrats!!
I am surprised that we trigger installs (of pm2, of NGINX…) conditionally based on a variable passed. I find it confusing that the playbook calls the same roles twice with a install: false
variable the second time. I understand that a configuration management system should always define the dependencies to be installed, and that it is up to the system to assess whether the install is necessary or not. Otherwise, I wonder if splitting the install and management in separate (admittedly tiny) roles would not be appropriate.
I tried to check locally with Vagrant, but I always get a 502 when trying to connect to http://localhost:8080/collection-api/v1/docs/
or any other variation. Are the forwarded ports up to date? If so, describing in the “Testing” section which URL to access would be useful.
I would personally welcome an Ansible provisioning in the Vagrantfile to speed up the testing process 🙂
tests/inventory.yml
Outdated
ansible_ssh_host: 127.0.0.1 | ||
|
||
ota_source_repository: https://github.com/OpenTermsArchive/demo-declarations.git | ||
ota_source_repository_branch: test-new-config |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be updated before merge.
tests/pm2.config.cjs
Outdated
args: 'run start:federation-api', | ||
max_restarts: 2, | ||
min_uptime: '1h', // Set a relatively high duration (more than the longest run) so that restarts that occur before this duration has elapsed are considered unstable. | ||
restart_delay: 15 * 60 * 1000, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This value seems too low for that app that reusers might depend on.
I considered it, but as a tester, I prefer to have full control over the playbook execution and maintain a clear separation between Vagrant VM initialization and playbook execution. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The README is really neat and readable with this file-based approach, love it!
And the infrastructure setup code is just… beautiful 🥲
Really good results after this pass of polish, congratulations!
README.md
Outdated
These variables can be defined in the inventory file, for example: | ||
The `inventory.yml` file defines the hosts and the variables required for the deployment. This file should contain all the necessary variables as described below. | ||
|
||
| Variable | Description | Required or default Value | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| Variable | Description | Required or default Value | | |
| Variable | Description | Required or default value | |
README.md
Outdated
ota_source_repository_branch: main | ||
ota_directory: demo | ||
ota_source_repository_branch: master | ||
ota_directory: opentermsarchive-demo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case, wouldn't “demo” be a valid example? I understand that the “name of the repository” default would be
demo-declarations
and notdemo
, and that it would thus be relevant to setota_directory: demo
.
apply: | ||
become: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we
apply
thebecome
here rather thanbecome
in the role itself? Is there a way in whichmongo/configure
can run withoutbecome
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I decided to manage all become: true
settings at the playbook level for the following reasons:
- Centralization of privilege escalation in one place.
- Setting
become: true
once at the playbook level simplifies the roles, avoiding repetitive configuration in each task.
However, this approach has some drawbacks:
- It might escalate privileges for tasks that don't require it, but this it seems to me that it is not an issue in our case as each task in infrastructure need privileges.
- It reduces the control over which specific tasks need privilege escalation. However, the way our roles are structured means this granularity is not necessary.
Another solution considered was using block
in roles to wrap all tasks with a become: true
instruction. However, similar to defining global variables, I believe it is clearer to specify where privilege escalation will occur at the entry point of the playbook.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amazing, thank you for these clear explanations!
- name: Install Node | ||
ansible.builtin.include_role: | ||
name: node | ||
- name: Set required variables |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extracting this into a dedicated role would make
deploy
even more readable 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so, I prefer to have a top down approach for global variables
--- | ||
- name: Configure MongoDB | ||
notify: Restart MongoDB | ||
block: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this all in a
block
instead of having 3 steps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the notify
@@ -0,0 +1,6 @@ | |||
--- | |||
- name: Install NGINX package |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Considering how small that role is, I would also have been fine seeing it straight in the playbook 🙂
Co-authored-by: Clément Biron <[email protected]>
Co-authored-by: Clément Biron <[email protected]>
Co-authored-by: Clément Biron <[email protected]>
Co-authored-by: Matti Schneider <[email protected]>
Co-authored-by: Matti Schneider <[email protected]>
Co-authored-by: Matti Schneider <[email protected]>
No description provided.