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

Agent MSI support #212

Merged
merged 35 commits into from
Jan 29, 2024
Merged

Agent MSI support #212

merged 35 commits into from
Jan 29, 2024

Conversation

amitkanfer
Copy link
Contributor

@amitkanfer amitkanfer commented Nov 19, 2023

  • Support basic functionality e2e (copy files and execute agent install from the target folder)
  • Support uninstall
  • Check return code from agent install and fail execution if code is different than 0
  • Support custom installation folder (EDIT: not sure this is needed. See comment here)
  • Implement the buildkite logic to trigger an MSI build whenever there's a new Agent version (similar to the logic we have with beats)
  • Cleanup all temp files after agent install is executed successfully
  • check installation with endpoint
  • check upgrade flow

To test, run from a command prompt with administrator permissions:

elastic-agent.msi INSTALLARGS="--url=<URL> --enrollment-token=<TOKEN>"

Another option, with logs collection:

msiexec -i elastic-agent.msi INSTALLARGS="--url=<URL> --enrollment-token=<TOKEN>" -L*V "log.txt"

Few notes:

  • If INSTALLARGS are not provided, the MSI will copy the files to a temp folder and finish.
  • If INSTALLARGS are provided, the MSI will copy the files to a temp folder and then run the elastic-agent install command with the provided args. If the install flow is successful, the temp folder is deleted.
  • If INSTALLARGS are provided but the elastic-agent install command fails - the top folder is NOT deleted to allow further troubleshooting.
  • MSI uninstall will call elatic-agent uninstall on a "best effort" basis and will always finish successfully (if not, a 3rd party tool will be needed to remove the windows service)
  • upgrades are not supported, and in fact prevented as implemented here. Upgrades shall happen via fleet.
  • if the elastic-agent install command fails (for any reason), the MSI will rollback all changes.

@amitkanfer amitkanfer requested a review from a team as a code owner November 19, 2023 20:37
@amitkanfer amitkanfer requested a review from leehinman November 19, 2023 20:37
@amitkanfer amitkanfer mentioned this pull request Nov 19, 2023
7 tasks
@nimarezainia
Copy link

@amitkanfer is it possible to have the MSI set the --base-path option for the agent install command? (as @cmacknz mentions here)?

Setting the path was a big requirement from enterprises and I can't see any reason why it wouldn't also be a requirement for the same set of users who would want to utilize the MSI (aside from Defend users of course). it would be great not to have diverging product behaviors if possible. (of course I am saying this not knowing what the amount of effort involved exactly is)

@amitkanfer
Copy link
Contributor Author

i'll look into that @nimarezainia . My concern is more around the uninstall flow. Not sure how the new base path will be available to the "add/remove features" and the other native Windows applications. Probably a solved problem, but i just need to understand them.

@amitkanfer
Copy link
Contributor Author

I also need to check and implement upgrade flows. editing the description

@cmacknz cmacknz requested a review from a team November 23, 2023 19:02
Copy link
Member

@cmacknz cmacknz left a comment

Choose a reason for hiding this comment

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

When this gets merged, at what point is it included in the stack release process? Does it show up in the snapshots for the next minor and would be released what that version is released? Or is there more work to do to have this actually show up in the downloads page for agent?

Following from having a way to build this, we need a way to test it. Likely we can do this as an agent integration test, but since this isn't actually packaged from the agent repository we'd only want the test to run every time there is a new snapshot (or once per day or something).

@@ -68,6 +68,12 @@ static bool FromFilenameOrUrl(string fileName, string url, out ArtifactPackage a
Architecture = rxGroups["arch"].Value.ToLower();
IsSnapshot = !rxGroups["snapshot"].Value.IsEmpty();

// HACK
Copy link
Member

Choose a reason for hiding this comment

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

Is there a better way to do this, or will this live on forever :)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

that's a very good question :)

@amitkanfer
Copy link
Contributor Author

@cmacknz

When this gets merged, at what point is it included in the stack release process?

There will be a follow up PR to make the necessary changes in the pipelines. @dliappis is will be reviewing the work. We should be able to first merge this PR, make sure there's no impact on existing (beats) MSIs, and then trigger the agent MSI flow.

At the moment, i'm focused on testing the install / upgrade / uninstall flows. Once they work 100% i'll cleanup the PR and go through the review cycle

@amitkanfer
Copy link
Contributor Author

Will try following https://stackoverflow.com/a/17790056 to show error messages to the end user. Note that this is valid only when running the installer w/o MDMs

process.StartInfo.CreateNoWindow = true;
session.Log("Running command: " + process.StartInfo.FileName + " " + process.StartInfo.Arguments);
process.Start();
session.Log(process.StandardOutput.ReadToEnd());
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we also log process.standarderror?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it's trickier to do both and didn't succeed on the first try... so yes, we should, will work on it

Copy link
Contributor Author

Choose a reason for hiding this comment

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

for now i just switched to stderr instead of stdout

System.Diagnostics.Process process = new System.Diagnostics.Process();
process.StartInfo.WorkingDirectory = install_folder;
process.StartInfo.FileName = Path.Combine(install_folder, "elastic-agent.exe");
process.StartInfo.Arguments = "install -f " + install_args;
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we consider always adding --delay-enroll so that installation success doesn't depend on fleet service reachability + valid API token?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

one of the tasks was to make sure the service was up and running right after the installation flow... Don't you think the admin would want to know if the token is wrong when rolling out agent installations?

dliappis and others added 8 commits January 18, 2024 16:49
As the release manager can't trigger the workflow introduced in
566b9e4 , we maintain the old
way of building snapshot/staging beats artifacts by keeping the
trigger pipeline only for that branch.

Note: this means that this PR **MUST NOT** be backported to the
elastic-stack-installers 7.17 branch.

Details: https://elasticco.atlassian.net/browse/REL-1004?focusedCommentId=107973
Add Install, Upgrade, and Uninstall MSI tests using Pester w/ Powershell Core
@alpar-t alpar-t merged commit 887274a into main Jan 29, 2024
2 of 3 checks passed
@alpar-t alpar-t deleted the agent_support branch January 29, 2024 18:00
alpar-t pushed a commit that referenced this pull request Jan 29, 2024
* first draft

* 6

* 6

* Preventing agent upgrade via MSI

* Update src/installer/BeatPackageCompiler/BeatPackageCompiler.cs

Co-authored-by: Craig MacKenzie <[email protected]>

* Update README.md

* Update README.md

* Fixing uninstall flow and install cleanup flow

* rolling back if agent install command fails

* redirecting stdout to MSI log

* Failing the uninstall flow in case agent uninstall command fails

* Don't attempt calling agent install if the file doesn't exist

* adding BK logic (#219)

* Update build.ps1

* Clean up path length

Instead of re-cloning to a checkout with a shorter path,
we rename the existing BK checkout.

* Fix 798ff24

* Typo

* Build from MANIFEST_URL and don't sign

This commit implements the refactoring to allow
a short term integration with the unified release.
It's meant to be triggered by getting passed a $MANIFEST_URL
and $DRA_WORKFLOW env var.

* Update README.md

Co-authored-by: Craig MacKenzie <[email protected]>

* Update README.md

Co-authored-by: Craig MacKenzie <[email protected]>

* Update README.md

Co-authored-by: Craig MacKenzie <[email protected]>

* Update README.md

Co-authored-by: Craig MacKenzie <[email protected]>

* Redirecting stderr and removing PATH manipulation for Agent MSI

* Remove cron schedule

As discussed in https://elasticco.atlassian.net/browse/REL-1004?focusedCommentId=107598

* Trigger 7.17 beats DRA using schedule

As the release manager can't trigger the workflow introduced in
566b9e4 , we maintain the old
way of building snapshot/staging beats artifacts by keeping the
trigger pipeline only for that branch.

Note: this means that this PR **MUST NOT** be backported to the
elastic-stack-installers 7.17 branch.

Details: https://elasticco.atlassian.net/browse/REL-1004?focusedCommentId=107973

* Making sure Agent MSI runs as an administrator

* Add MSI tests for Agent Pipeline (#220)

Add Install, Upgrade, and Uninstall MSI tests using Pester w/ Powershell Core

* Enabling agent tests

* Disable "Default" test case as it doesn't exist anymore. Don't fail build on test failure for now.

* Default mode clean-up

* Update build.ps1

---------

Co-authored-by: Craig MacKenzie <[email protected]>
Co-authored-by: Dimitrios Liappis <[email protected]>
Co-authored-by: William Easton <[email protected]>
Co-authored-by: William Easton <[email protected]>
dliappis added a commit to dliappis/elastic-stack-installers that referenced this pull request Jan 30, 2024
This commit fixes a bug introduced in PR elastic#212 which missed the switch
from WORKFLOW -> DRA_WORKFLOW from the publish step, resulting
in failures[^1].

[^1]: https://buildkite.com/elastic/elastic-stack-installers/builds/3641#018d5b0b-5ae5-404c-b79f-211468f45413/51-52
@dliappis dliappis mentioned this pull request Jan 30, 2024
dliappis added a commit that referenced this pull request Jan 30, 2024
This commit fixes a bug introduced in PR #212 which missed the switch
from WORKFLOW -> DRA_WORKFLOW from the publish step, resulting
in failures[^1].

[^1]: https://buildkite.com/elastic/elastic-stack-installers/builds/3641#018d5b0b-5ae5-404c-b79f-211468f45413/51-52
dliappis added a commit that referenced this pull request Jan 30, 2024
This commit fixes a bug introduced in PR #212 which missed the switch
from WORKFLOW -> DRA_WORKFLOW from the publish step, resulting
in failures[^1].

[^1]: https://buildkite.com/elastic/elastic-stack-installers/builds/3641#018d5b0b-5ae5-404c-b79f-211468f45413/51-52
dliappis added a commit that referenced this pull request Jan 31, 2024
This commit fixes the downloaded artifacts path to the expected path
by the release manager image (`bin/out`).

The original path was changed in #212 and the previous step because path
lengths exceeded a limit imposed by the msi builder.
dliappis added a commit that referenced this pull request Jan 31, 2024
This commit fixes the downloaded artifacts path to the expected path by the release manager image (bin/out).

The original path was changed in #212 and the previous step because path lengths exceeded a limit imposed by the msi builder.
dliappis added a commit that referenced this pull request Jan 31, 2024
This commit fixes the downloaded artifacts path to the expected path by the release manager image (bin/out).

The original path was changed in #212 and the previous step because path lengths exceeded a limit imposed by the msi builder.
dliappis added a commit to dliappis/elastic-stack-installers that referenced this pull request Jan 31, 2024
DaveSys911 pushed a commit that referenced this pull request Jan 31, 2024
* Revert "Fix artifacts path for dra publish (#227)"

This reverts commit 2739036.

* Revert "Fix dra publish step (#226)"

This reverts commit 98f830a.

* Revert "Agent MSI support (#212)"

This reverts commit ffffea6.
dliappis added a commit that referenced this pull request Feb 2, 2024
This commit fixes the downloaded artifacts path to the expected path by the release manager image (bin/out).

The original path was changed in #212 and the previous step because path lengths exceeded a limit imposed by the msi builder.
dliappis added a commit that referenced this pull request Feb 2, 2024
PR #212 made some changes on `main` that require the presence of
`MANIFEST_URL`. However, the pipeline is still configured to run the
same script when a PR (from an upstream branch) is raised and it
currently fails.

This commit skips tests when triggered from another pipeline (unified
release), and allows running tests when triggered by PR creation by
picking up a suitable `MANIFEST_URL`.
dliappis added a commit that referenced this pull request Feb 7, 2024
PR #212 made some changes on `main` that require the presence of `MANIFEST_URL`. However, the pipeline is still configured
to run the same script when a PR (from an upstream branch) is raised and it currently fails.

This commit skips tests when triggered from another pipeline (unified release), and allows running tests when triggered by PR creation
by picking up a suitable `MANIFEST_URL`. DRA publishing is skipped unless we are triggered from the unified release.

Closes elastic/ingest-dev#2895
@mbudge
Copy link

mbudge commented Apr 17, 2024

When will this be GA with supporting documentation? Says it's beta.

@nimarezainia
Copy link

@mbudge we are looking at 8.14 for GA and docs will be ready then.

@kilfoyle
Copy link

@amitkanfer , @nimarezainia I've opened the issue above for the docs.

Amit, I'd really appreciate if you, or anyone, can provide the install steps and any other details users will need. Also, are there any UI changes planned? Thanks!

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.

9 participants