Posit Connect support for off-host content execution has entered General Availability (GA).
Documentation about off-host execution is now included in the
Connect Admin Guide.
The instructions presented here were associated with the off-host execution beta and are now obsolete.
Appendix: Architecture Overview
Local Execution
Posit Connect has traditionally executed R, Python, and other content types using local processes running on the same Linux host as the Posit Connect server process.
This style of deployment can happen with bare-metal servers, with virtual machines, or inside a container. Using this model, Posit Connect is able to be deployed within Kubernetes, but all of its managed processes occur within the same container.
Remote Execution
Posit Connect can use Kubernetes to execute R, Python, and other content types. These jobs are external to the server or container that is running Posit Connect.
In this scenario, Posit Connect launches a job to service requests for a Shiny application. That job uses an image appropriate for that content. For our Shiny example, Posit Connect identifies an image that contains a version of R that is compatible with the version used during development. When the job is launched, the container is augmented with a handful of required runtime components using a separate, auxiliary Posit Connect init-container. The use of an init-container to prepare the runtime components means that the content image does not need to be rebuilt for a particular version of Posit Connect. For more details about the init-container, see the Runtime Init Container section below.
The launched jobs mount a number of directories into the running container. These directories contain the variable data associated with your content, such as the source code, output directories, and process logs. These locations are normally mounted using NFS, but can also use host mounts.
Containerized Operation
When Posit Connect is running in Kubernetes mode, the change will be transparent to users—they will continue to deploy, view, and interact with content the same as before. However, when Posit Connect launches a process to prepare a build environment (installing R or Python packages), render a document, or run an interactive application, it will do so using a Kubernetes container instead of a local process.
Posit Connect will automatically select the most appropriate image from the options defined in the ClusterDefinition YAML file(s). See Image selection for more details about the selection process.
Posit Connect will respect Runtime settings as usual, but each process will run in a separate container. For example, an application with Max processes set to 3 might result in up to 3 separate Kubernetes Jobs, each running one content process. Process logs will be available in the Connect dashboard as usual.
The Processes table on the Metrics pane in the Admin section of the Posit Connect dashboard will show processes running across the cluster. However, the other charts (CPU, RAM, etc.) will only report resource usage for the Posit Connect server you are connected to.
Job Launcher
Posit Connect bundles a specific version of the Posit Job Launcher with each Posit Connect release. Posit Connect fully manages the lifecycle of the Launcher process. The necessary Launcher configuration files are generated by Posit Connect at runtime. To avoid potential conflicts with any other Launcher installation being used by Posit Workbench, Posit does not recommend running Posit Connect on the same server as Posit Workbench.
Note that because Posit Connect generates the Launcher configurations at runtime, some Launcher configurations are not exposed as Posit Connect settings and the corresponding Launcher configuration cannot be overridden.
The following table illustrates the default values for the various Posit Connect and Launcher configurations that have potential for conflict. When modifying any of the these settings, care must be taken to ensure that there is no conflict with another instance of the Launcher (including other instances of Posit Connect with Launcher enabled).
| Connect config key | Connect default | Launcher default | Launcher config file | Launcher config key |
|---|---|---|---|---|
Launcher.ConfigDir |
/etc/rstudio-connect/launcher |
/etc/rstudio |
N/A | N/A |
Launcher.ScratchPath |
/var/lib/rstudio-connect-launcher |
/var/lib/rstudio-launcher |
launcher.conf |
scratch-path |
| N/A | ${Launcher.ScratchPath}/Kubernetes |
/var/lib/rstudio-launcher/Kubernetes |
launcher.kubernetes.conf |
scratch-path |
Launcher.KubernetesNamespace |
rstudio-connect |
rstudio |
launcher.kubernetes.conf |
kubernetes-namespace |
Launcher.KubernetesProfilesConfig |
${Launcher.ConfigDir}/launcher.kubernetes.profiles.conf |
/etc/rstudio/launcher.kubernetes.profiles.conf |
launcher.kubernetes.conf |
profile-config |
Runtime Init Container
To make the maintenance of content images as seamless as possible for our users, Posit Connect utilizes an Init Container when running content on Kubernetes. The purpose of this initialization is to copy the runtime artifacts required by Posit Connect into your container just before your content starts to execute. This architecture means that the image being used to execute your content does not need to contain any Posit Connect components, and thus, does not need to be rebuilt after an Posit Connect upgrade.
Posit maintains an init-container image which is 1:1 with the Posit Connect version. When a content execution Pod is created in Kubernetes, Posit Connect also creates an EmptyDir volume (rsc-volume in the image below). This empty directory is used as a staging area for our runtime components. The init-container is then responsible for copying the runtime artifacts into the staging area so that they are also available to the content container.
