From 3e73b279711f06fa158f38dbfbe5694ac830c3de Mon Sep 17 00:00:00 2001 From: adrianpedriza Date: Thu, 6 Jul 2023 09:46:31 +0200 Subject: [PATCH 1/5] add hybrid dev mode docs Signed-off-by: adrianpedriza --- src/content/reference/manifest.mdx | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/src/content/reference/manifest.mdx b/src/content/reference/manifest.mdx index c66d2958a..e08bfab64 100644 --- a/src/content/reference/manifest.mdx +++ b/src/content/reference/manifest.mdx @@ -497,7 +497,7 @@ lifecycle: - `postStart`: specifies if the postStart event is enabled when running `okteto up` (default: `false`). - `postStop`: specifies if postStop event is enabled when running `okteto up` (default: `false`). -#### metadata (object, optional) +#### metadatassss (object, optional) The metadata field allows to inject labels and annotations into your development container. @@ -509,6 +509,28 @@ metadata: custom.label/dev: "true" ``` +#### mode (string, optional) + +The development mode used for a development environment. There are two options available for this field: + +- `sync`: the standard and default mode. This mode will synchronize your code with the development container. +- `hybrid`: use this mode if you want to run your service locally but run the rest of your application components in the cluster. + +The motivation for this field comes from the fact that adopting a `hybrid` approach can sometimes provide a faster development experience because in general the local machine is faster than our development containers, saving e.g. service build time. On the other hand, it should be noted that developing with the service running locally breaks replicability between OS in addition to the added latency when accessing the rest of the services in the cluster. + +If you want to use the hybrid mode, you only need to configure the necessary ports to expose the service running on your local machine to the development container in remote so that the rest of the components running on the cluster can communicate with the development container as if it were the one running the application remotely. To do that, you can make use of the [reverse](reference/manifest.mdx#reverse) field, which will expose the indicated port of your local machine to the desired port on the development container. + +```yaml +dev: + frontend: + mode: hybrid + reverse: + - 3000:8080 + workdir: ./frontend + command: ["yarn start"] +``` + +in the example shown we have indicated that we develop the `frontend` service locally using the `mode: hybrid` field. The service running locally will execute the command defined in the `command` field in the directory indicated in `workdir`. In addition, the application will expose on port `3000` of the development container what it exposes on port `8080` of the local machine, making it possible for other components running on the cluster to access the service as if it were running remotely. #### nodeSelector (map[string]string, optional) List of labels that the node must have to include the development container on it. From bb758f01e220c6be97f1cdf625d78fa8d4dc39cb Mon Sep 17 00:00:00 2001 From: adrianpedriza Date: Thu, 6 Jul 2023 09:48:37 +0200 Subject: [PATCH 2/5] undo change Signed-off-by: adrianpedriza --- src/content/reference/manifest.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/reference/manifest.mdx b/src/content/reference/manifest.mdx index e08bfab64..bf6f78847 100644 --- a/src/content/reference/manifest.mdx +++ b/src/content/reference/manifest.mdx @@ -497,7 +497,7 @@ lifecycle: - `postStart`: specifies if the postStart event is enabled when running `okteto up` (default: `false`). - `postStop`: specifies if postStop event is enabled when running `okteto up` (default: `false`). -#### metadatassss (object, optional) +#### metadata (object, optional) The metadata field allows to inject labels and annotations into your development container. From d933df28503fb71d4bdf56c20dcf280e2871ef10 Mon Sep 17 00:00:00 2001 From: Nicklas Gummesson Date: Thu, 6 Jul 2023 11:36:17 +0200 Subject: [PATCH 3/5] Ingress improvements --- src/content/reference/manifest.mdx | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/content/reference/manifest.mdx b/src/content/reference/manifest.mdx index bf6f78847..418fb90c2 100644 --- a/src/content/reference/manifest.mdx +++ b/src/content/reference/manifest.mdx @@ -511,10 +511,11 @@ metadata: #### mode (string, optional) -The development mode used for a development environment. There are two options available for this field: +Defines how `okteto up` will behave. -- `sync`: the standard and default mode. This mode will synchronize your code with the development container. -- `hybrid`: use this mode if you want to run your service locally but run the rest of your application components in the cluster. +Currently two options are available: +- `sync`: (default) Run service in a remote development container. Synchronizes your code with the container. +- `hybrid`: Runs service in your local computer instead of in a remote development container. Traffic needs to be "reversed" in order to communicate with the rest of the components running in your cluster. The motivation for this field comes from the fact that adopting a `hybrid` approach can sometimes provide a faster development experience because in general the local machine is faster than our development containers, saving e.g. service build time. On the other hand, it should be noted that developing with the service running locally breaks replicability between OS in addition to the added latency when accessing the rest of the services in the cluster. @@ -531,6 +532,7 @@ dev: ``` in the example shown we have indicated that we develop the `frontend` service locally using the `mode: hybrid` field. The service running locally will execute the command defined in the `command` field in the directory indicated in `workdir`. In addition, the application will expose on port `3000` of the development container what it exposes on port `8080` of the local machine, making it possible for other components running on the cluster to access the service as if it were running remotely. + #### nodeSelector (map[string]string, optional) List of labels that the node must have to include the development container on it. From 53600375f0f77620d1069ae8567640d68413231e Mon Sep 17 00:00:00 2001 From: Nicklas Gummesson Date: Thu, 6 Jul 2023 15:16:55 +0200 Subject: [PATCH 4/5] Elaborate on hybrid mode --- src/content/reference/manifest.mdx | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/src/content/reference/manifest.mdx b/src/content/reference/manifest.mdx index 418fb90c2..a416fc3eb 100644 --- a/src/content/reference/manifest.mdx +++ b/src/content/reference/manifest.mdx @@ -511,13 +511,24 @@ metadata: #### mode (string, optional) -Defines how `okteto up` will behave. +Defines how `okteto up` will setup the development container and behave within the cluster. Currently two options are available: -- `sync`: (default) Run service in a remote development container. Synchronizes your code with the container. -- `hybrid`: Runs service in your local computer instead of in a remote development container. Traffic needs to be "reversed" in order to communicate with the rest of the components running in your cluster. +- `sync`: (default) Sync & run your code in a remote development container. +- `hybrid`: Run your code on your local computer instead of in a remote development container, while rest of your service components runs in your remote cluster. -The motivation for this field comes from the fact that adopting a `hybrid` approach can sometimes provide a faster development experience because in general the local machine is faster than our development containers, saving e.g. service build time. On the other hand, it should be noted that developing with the service running locally breaks replicability between OS in addition to the added latency when accessing the rest of the services in the cluster. +Most use-cases should use default `sync` mode, but `hybrid` may be desired to achieve a faster development experience in some scenarios: + +| | `sync` | `hybrid` | +|---|---|---| +| Soure code | Uses Syncthing to sync files bidirectionally with your remote development container | Uses local source code directly, no files syncing needed | +| `command` context | Runs in the _remote development container_ | Runs on your _local machine_, so traffic need to be rerouted from/to cluster, e.g. using `reverse` option | + +##### `hybrid` motivation and example + +A typical use-case and motivation for using `hybrid` is when developing a service that require "very fast" file-change-to-reload times. Frontend development tooling (e.g. Webpack) is a common example. Since hybrid mode avoids having to sync file changes to remote development container and wait for the container to detect file changes to trigger a rebuild, it's typically order-of-magnitude faster than `sync` mode. + +On the other hand, with the service running locally breaks replicability between OS, and may add latency when accessing the rest of the services in the cluster. But it's usually an OK tradeoff for development purposes. If you want to use the hybrid mode, you only need to configure the necessary ports to expose the service running on your local machine to the development container in remote so that the rest of the components running on the cluster can communicate with the development container as if it were the one running the application remotely. To do that, you can make use of the [reverse](reference/manifest.mdx#reverse) field, which will expose the indicated port of your local machine to the desired port on the development container. @@ -528,7 +539,7 @@ dev: reverse: - 3000:8080 workdir: ./frontend - command: ["yarn start"] + command: ["npx webpack watch --mode development"] ``` in the example shown we have indicated that we develop the `frontend` service locally using the `mode: hybrid` field. The service running locally will execute the command defined in the `command` field in the directory indicated in `workdir`. In addition, the application will expose on port `3000` of the development container what it exposes on port `8080` of the local machine, making it possible for other components running on the cluster to access the service as if it were running remotely. From 02df62acb86349d31b91d07330ee88f3489a1bad Mon Sep 17 00:00:00 2001 From: Nicklas Gummesson Date: Tue, 18 Jul 2023 12:20:25 +0200 Subject: [PATCH 5/5] Reduce reference docs --- src/content/reference/manifest.mdx | 29 +---------------------------- 1 file changed, 1 insertion(+), 28 deletions(-) diff --git a/src/content/reference/manifest.mdx b/src/content/reference/manifest.mdx index a416fc3eb..d1e00137d 100644 --- a/src/content/reference/manifest.mdx +++ b/src/content/reference/manifest.mdx @@ -511,39 +511,12 @@ metadata: #### mode (string, optional) -Defines how `okteto up` will setup the development container and behave within the cluster. +Defines how [`okteto up`](/reference/cli/#up) will setup the development container and behave within the cluster. Currently two options are available: - `sync`: (default) Sync & run your code in a remote development container. - `hybrid`: Run your code on your local computer instead of in a remote development container, while rest of your service components runs in your remote cluster. -Most use-cases should use default `sync` mode, but `hybrid` may be desired to achieve a faster development experience in some scenarios: - -| | `sync` | `hybrid` | -|---|---|---| -| Soure code | Uses Syncthing to sync files bidirectionally with your remote development container | Uses local source code directly, no files syncing needed | -| `command` context | Runs in the _remote development container_ | Runs on your _local machine_, so traffic need to be rerouted from/to cluster, e.g. using `reverse` option | - -##### `hybrid` motivation and example - -A typical use-case and motivation for using `hybrid` is when developing a service that require "very fast" file-change-to-reload times. Frontend development tooling (e.g. Webpack) is a common example. Since hybrid mode avoids having to sync file changes to remote development container and wait for the container to detect file changes to trigger a rebuild, it's typically order-of-magnitude faster than `sync` mode. - -On the other hand, with the service running locally breaks replicability between OS, and may add latency when accessing the rest of the services in the cluster. But it's usually an OK tradeoff for development purposes. - -If you want to use the hybrid mode, you only need to configure the necessary ports to expose the service running on your local machine to the development container in remote so that the rest of the components running on the cluster can communicate with the development container as if it were the one running the application remotely. To do that, you can make use of the [reverse](reference/manifest.mdx#reverse) field, which will expose the indicated port of your local machine to the desired port on the development container. - -```yaml -dev: - frontend: - mode: hybrid - reverse: - - 3000:8080 - workdir: ./frontend - command: ["npx webpack watch --mode development"] -``` - -in the example shown we have indicated that we develop the `frontend` service locally using the `mode: hybrid` field. The service running locally will execute the command defined in the `command` field in the directory indicated in `workdir`. In addition, the application will expose on port `3000` of the development container what it exposes on port `8080` of the local machine, making it possible for other components running on the cluster to access the service as if it were running remotely. - #### nodeSelector (map[string]string, optional) List of labels that the node must have to include the development container on it.