Automatic upgrades - Githubissues

gravitational / teleport

The easiest, and most secure way to access and protect all of your infrastructure.

https://goteleport.com

GNU Affero General Public License v3.0

17.35k stars 1.74k forks source link

Automatic upgrades #3121

Closed klizhentas closed 1 year ago

klizhentas commented 4 years ago

Description

Teleport should support automatic upgrade system both for clients and servers

Rationale

Automatic upgrades improve security of the system, improve user experience through delivering newer versions, reduce the amount of support by keeping large deployments of infrastructure up to date.

Design

TBD.

benarent commented 4 years ago

Feedback from customer c-tm -> Able to do the upgrade in a controlled fashion for PCI reasons. Staged Deployment. -> OSS Mirror / RPM. Internally then promote those repos to sets of systems.

russjones commented 4 years ago

Best: 10 Worst: 25

russjones commented 4 years ago

Target for design document is mid-August and beta is mid-September.

matta10x commented 3 years ago

Ideally for Debian/Ubuntu users, there'd be a Teleport repo so that users can download/install new versions when they run apt update/upgrade.

sover02 commented 3 years ago

++ for this feature :)

russjones commented 2 years ago

Plan

Phase	PR	Date
~Phase 0: RFD~	~#10690~	~Q1 2022~
~Phase 1: Inventory Control~	~#12715~	~Q2 2022 - Teleport 10~
~Phase 2: Notification-only~		~Q3 2022 - Teleport 10.2~
Phase 3: Script-based Upgrades		Q4 2022 - Teleport 11.2
Phase 4: Cloud
Phase 5: TUF-based Upgrades		Q1 2023 - Teleport 12.x
Phase 6: Anonymized metrics		Unknown

Scope

Phase 3: Script-based Upgrades

11.2

Script-based installers (using apt/rpm, curl, etc)
Manually (using tctl) run script on defined subset of nodes to upgrade
Add support for RBAC to support Teleport Cloud

Cloud

Add automatic enrollment into script-based upgrades for all Cloud tenants.

12.1

Rollout configuration: Selecting which script runs on which machine
Rollout configuration: Halt rollout based on failure threshold
Rollout configuration: Scheduling for rollouts to occur at defined time
Rollout configuration: Local rollback (cache old binary, and support rollback)
Rollout configuration: Plan/apply workflow

russjones commented 1 year ago

@klizhentas @xinding33 @fspmarshall

Long term our plan is for OSS users to opt-in to anonymized metrics to use script-based upgrades.

However, for 11.2 we don't have any thing to anonymize metrics for OSS users or infrastructure to receive anonymized metrics.

I propose we still prompt OSS users to opt-in to anonymized metrics when using script-based upgrades. Nothing will actually be sent, it will just be a prompt that requires the user to accept. If we don't do this now and wait until have infrastructure to receive anonymized metrics it will feel like we are taking something away from users.

What do you think?

klizhentas commented 1 year ago

@russjones

This upgrade system metrics section is obsolete because it was written pre-posthog. Please updated it to make it similar to connect anonymized metrics RFD that use pre-hog (our anonymized collection endpoint)

zmb3 commented 1 year ago

I'm going to close this in favor of #21516, which is more up to date with our latest thinking on this topic.