search

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
16.96k stars 1.7k forks source link

[Binary size] Make slimmed down Teleport binaries available #8735

Open Valien opened 2 years ago

Valien commented 2 years ago

What

Per this thread -- https://goteleport.slack.com/archives/CEZH6UL64/p1635093861038200

Would be neat to have a slimmed-down binary designed for resource-constrained IoT devices that only run the SSH service.

How

Remove extra files, web assets, etc that wouldn't be required to run Teleport. Can even put the other services behind build tags to avoid compiling in a bunch of unused code.

Why

For small storage IoT devices

Workaround

Manual build possibly with our OSS. Not fully supported by Teleport potentially.

Valien commented 2 years ago

@zmb3 ^ let me know if I'm missing anything. Good idea on this.

zmb3 commented 2 years ago

cc @xinding33 as I recall binary size coming up in recent conversations

Valien commented 1 year ago

Recent public ask on this here: https://goteleport.slack.com/archives/CEZH6UL64/p1664440266784029

Customers are building their own packages and stripping out the other non-needed binaries like tbot, tsh, tctl, etc.

Valien commented 1 year ago

@xinding33 or @zmb3 - any updates around this? @gaille-teleport and I were on a customer call and this was brought up as a concern due to their fleet of IoT devices and current Teleport binaries are taking up a lot of the available local storage.

Gunni commented 1 year ago

How about splitting the teleport code into separate packages, such as libteleport (for shared code), teleport-ssh (just ssh_server stuff), etc?

bendoerr commented 10 months ago

Just want to vote for this. We are considering starting an effort to patch and maintain a slim version for this use case. Besides the binary size itself, it's a bit egregious on memory usage due to the large binary footprint as well.

We are already building out PAM, etc that we can with build flags and no static assets. However the binary is still over 100M. Real world usage sees the resident memory footprint idle around 120M and when a shell session is established and additional ~110M due to the exe. For most Linux IoT devices, this is about 1/2 their available memory.

philip-teleport commented 5 months ago

+1 - needed for resource-constrained IoT devices

ean commented 5 months ago

We would also like this for virtual machines running in multiple public clouds (AWS, GCP, Azure, ...).

We want to run the agent on Cloud-hosted VMs that we operate and maintain for our users (software and OS upgrades, maintenance, etc.). As much memory as possible of the VMs memory should be available to our customers for them to handle their use cases with as small VMs as possible.