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

Move Acquia DB backups to cloud v2. #218

Merged
merged 26 commits into from
Oct 14, 2024
Merged

Conversation

acidaniel
Copy link
Contributor

@acidaniel acidaniel commented Feb 28, 2023

https://palantir.atlassian.net/browse/DEV-32

Test Intructions:

  • Add this to an existing project and run composer install

  • Ensure in the build.yml from the existing project you have the following variables:

    # Configuration for targets/acquia.xml
    acquia:
     backups: 'artifacts/backups'
     site: 'palantirnet'
     database: 'palantirnet'
     env: prod (default one if not defined)
    
    • Ensure there is a .env with acquia clould credentials specified in the 1Password

    • Run ddev restart

    • Run ddev phing acquia-get-backup

    • Ensure backup was downloaded inside the backups directory specified in backups

    • Run ddev phing drupal-load-db and ensure database dump downloaded is imported correctly.

@acidaniel acidaniel changed the title WIP, Move Acquia DB backups to cloud v2. Move Acquia DB backups to cloud v2. Mar 1, 2023
composer.json Outdated Show resolved Hide resolved
protected function getLatestBackup($client, $environment_uuid) {
$backup = new DatabaseBackups($client);
$backups = $backup->getAll($environment_uuid, $this->database);
$filepath = $this->dir . '/' . $this->env . '_' . $this->database . '_' . 'sql.gz';
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jesconstantine The load from backups task will load any *sql.gz file that exists in the artifact/backups directory regardless the name.

Copy link
Contributor

@jesconstantine jesconstantine Mar 7, 2023

Choose a reason for hiding this comment

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

@acidaniel I think that's my concern. I think manual backups have a different file patterns but could get loaded instead of the one that we download from prod. To me this is the same issue as what we were discussing in slack here - but am I think about it correctly?

I added this to our build.yml to ensure the correct backup was loaded: https://github.com/palantirnet/wisdhs-public/pull/566/files#diff-0fad5e53ffd9ff1b0af504ff6c4d0961af03f34af69d9e00de527f2f29c9cb2bR50-R56

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jesconstantine I would love to see your commit, but I got 404 message :'( (you know why. Rub salt in the wound).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jesconstantine I just changed here the extension, I had a typo, please let me know if there something else to do here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jesconstantine I think I found a way to improve performance by 96% of loading database with only using Linux commands. Here is a bit of background:

  1. Using drupal-load-db was using a gunzip -c command that when I run it it took around 10 minutes to finish the import
  2. Using <exec executable="ddev"... took around 56 seconds to load, but this is not an option since we need to ensure we are outside the container. So this option is discarded.
  3. Figured out and reading that by using native Linux commands like gzip -dc in combination with a direct mysql command takes only 46 seconds

You can see how I am implementing it really straightforward. So following the general formula about performance improvement in percentage which is:

( new - old ) / old * 100%

We have:

(42 - 600)/600*100= -93

What do you think about this?

Copy link
Contributor

@jesconstantine jesconstantine Mar 9, 2023

Choose a reason for hiding this comment

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

I'm so sorry about posting that link, I wasn't thinking. 😦

Here's the snippet:

    build:
        # Configuration for the database loading utility.
      load_db:
        # Pattern to match gzipped dump files
        export_pattern: "./artifacts/*.sql.gz"
        file: "./artifacts/dhsinternet_d9_db_backup.sql.gz"

@acidaniel
Copy link
Contributor Author

@jesconstantine This is ready to be reviewed now. Since the package was removed now I'm getting issues in CircleCI, do you think we need to skip this file to be linted?

targets/install.xml Outdated Show resolved Hide resolved
Comment on lines 290 to 291
<!-- Copy .env.example file to store Acquia Cloud Credentials -->
<copy file="${build.thebuild.dir}/defaults/install/.env.example" todir="${application.startdir}" overwrite="true"/>
Copy link
Contributor

Choose a reason for hiding this comment

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

I know the .env.example currently only has Acquia data in it, but I could see it being useful for non-acquia hosted projects too, what do you think?

Should we copy the file somewhere more globally and add the platform specific data to it here instead?

@jesconstantine
Copy link
Contributor

jesconstantine commented Mar 7, 2023

@acidaniel you asked:

Since the package was removed now I'm getting issues in CircleCI, do you think we need to skip this file to be linted?

Can we either:

  • ensure the task that installs the acquia cloud API SDK package is run before running the tests?
  • exclude src/Acquia here, then run the new phing task to install the acquia cloud API SDK package, and then run through the code review commands specifically on src/Acquia

What do you think?

@acidaniel acidaniel requested a review from byrond March 24, 2023 18:29
defaults.yml Outdated
@@ -110,7 +113,7 @@ drupal:
# Database connection for Drupal.
database:
# This value is required, but a default is set in the-build.xml.
# database: drupal
database: db
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need to change the default in the-build.xml instead of overriding it by default here?

Copy link
Contributor

Choose a reason for hiding this comment

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

Instead of setting a default value here for the database name (which could break multisite behavior), I updated the default for the first database that gets copied with defaults/install/the-build/build.yml. See 90b7d7d

Now, when a multisite is added, and that default is not present, it defaults to the site directory name (as it did before this PR).

defaults.yml Show resolved Hide resolved
defaults.yml Show resolved Hide resolved
@byrond
Copy link
Contributor

byrond commented Apr 12, 2023

I confirmed the testing steps work on an existing project using this branch. I think we just need to address the issues mentioned above, and this will be good to go.

defaults.yml Show resolved Hide resolved
@@ -361,10 +196,15 @@ protected function validate() {
if (empty($this->database)) {
$this->database = $this->site;
}
// Check .env file exists.
if (!file_exists(".env")) {
throw new \BuildException(".env file is needed in the root of project with credentials see .env.example.");
Copy link
Contributor

Choose a reason for hiding this comment

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

This is checking for the .env file in the root, but it actually needs to exist in the .ddev directory for the environment variables to be created. I'm going to remove this, because the API already checks for the presence of these variables and fails accordingly:

example > acquia-get-backup:

[getacquiabackup] Couldn't find ACQUIA_CLOUD_API_KEY env variable.
[getacquiabackup] Couldn't find ACQUIA_CLOUD_API_SECRET env variable.

BUILD FAILED

@byrond byrond self-assigned this Mar 13, 2024
@byrond
Copy link
Contributor

byrond commented Oct 14, 2024

This was successfully tested on another client project and ready to merge.

@byrond byrond merged commit 7f7be9e into develop Oct 14, 2024
1 check passed
@byrond byrond deleted the cloud-api-version-2-backup branch October 14, 2024 17:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants