Skip to content
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

Merged
merged 49 commits into from
May 31, 2024
Merged

Conversation

Ndpnt
Copy link
Member

@Ndpnt Ndpnt commented May 20, 2024

No description provided.

@Ndpnt Ndpnt force-pushed the v2 branch 2 times, most recently from b4c32ae to b35766e Compare May 20, 2024 09:24
@Ndpnt Ndpnt requested review from MattiSG and clementbiron May 22, 2024 07:03
Copy link
Member

@clementbiron clementbiron left a 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.

roles/github/README.md Outdated Show resolved Hide resolved
playbooks/deploy.yml Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
Copy link
Member

@MattiSG MattiSG left a 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 🙂

CHANGELOG.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
tests/Vagrantfile Show resolved Hide resolved
ansible_ssh_host: 127.0.0.1

ota_source_repository: https://github.com/OpenTermsArchive/demo-declarations.git
ota_source_repository_branch: test-new-config
Copy link
Member

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 Show resolved Hide resolved
tests/pm2.config.cjs Outdated Show resolved Hide resolved
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,
Copy link
Member

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.

@Ndpnt
Copy link
Member Author

Ndpnt commented May 28, 2024

I would personally welcome an Ansible provisioning in the Vagrantfile to speed up the testing process 🙂

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.
Sometimes, I just want to initialize the VM, connect to it, check some things, and only then execute the playbook. Additionally, having everything defined in the Vagrantfile does not allow for refined execution with tags.
Finally, I'd prefer the playbook execution in test mode to be as close as possible to what I might need to do if I had to manipulate the production server with the playbook. This approach helps me become and remain familiar with the ansible-playbook command.
And when I need to repeat the clean setup multiple times, I simply run the following commands vagrant destroy -f && vagrant up && ansible-playbook ../playbooks/deploy.yml.

@Ndpnt Ndpnt requested a review from MattiSG May 29, 2024 15:17
Copy link
Member

@MattiSG MattiSG left a 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 |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
| 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
Copy link
Member

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 not demo, and that it would thus be relevant to set ota_directory: demo.

Comment on lines +68 to +69
apply:
become: true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we apply the become here rather than become in the role itself? Is there a way in which mongo/configure can run without become?

Copy link
Member Author

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.

Copy link
Member

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
Copy link
Member

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 🙂

Copy link
Member Author

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:
Copy link
Member

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?

Copy link
Member Author

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
Copy link
Member

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 🙂

tests/pm2.config.cjs Outdated Show resolved Hide resolved
tests/pm2.config.cjs Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
@Ndpnt Ndpnt merged commit ef9a99e into main May 31, 2024
1 check passed
@Ndpnt Ndpnt deleted the v2 branch May 31, 2024 12:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants