You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 2, 2023. It is now read-only.
So far, we've been starting nitriding and the enclave application via a shell script that starts nitriding in the background, and then proceeds to start the enclave application. That works just fine but it requires a shell, which is why we often base enclave images on Alpine. Alpine is a heavy dependency just for a shell.
We could work around this by teaching nitriding how to spawn (and subsequently monitor) the enclave application in the background, so we don't need a shell any more. This would allow for much simpler and smaller enclave images: all we need is a statically-compiled nitriding and enclave application.
Ideally, nitriding would terminate when it detects that the enclave application terminated. This has the added benefit that our Kubernetes pod is then also going to shut down. In our current shell script-based approach, the Kubernetes pod continues if nitriding terminated because it's a background process.
The text was updated successfully, but these errors were encountered:
Maybe this could be a command-line switch giving the command the launch?
In addition to monitoring, so nitriding could exit and terminate the container if the application exits, it could also wait until the network tunnel is established before launching, eliminating the sleep 1 we have in the middle of start.sh.
This commit adds a new command line flag that instructs nitriding to run
the given enclave application. Nitriding then blocks until the command
finishes (if ever) and prints both the command's stdout and stderr.
This feature has the advantage that one does not need a shell script to
start both nitriding and the enclave application, meaning that it's now
easier to build very slim Docker images that only contain a
statically-compiled nitriding and enclave application.
This fixes#58.
So far, we've been starting nitriding and the enclave application via a shell script that starts nitriding in the background, and then proceeds to start the enclave application. That works just fine but it requires a shell, which is why we often base enclave images on Alpine. Alpine is a heavy dependency just for a shell.
We could work around this by teaching nitriding how to spawn (and subsequently monitor) the enclave application in the background, so we don't need a shell any more. This would allow for much simpler and smaller enclave images: all we need is a statically-compiled nitriding and enclave application.
Ideally, nitriding would terminate when it detects that the enclave application terminated. This has the added benefit that our Kubernetes pod is then also going to shut down. In our current shell script-based approach, the Kubernetes pod continues if nitriding terminated because it's a background process.
The text was updated successfully, but these errors were encountered: