README.md

@@ -61,39 +61,14 @@ dagger call build --source=.
 ```
 
 This runs the `build` function defined in `dagger/src/index.ts` and passes `.`
-as the `source` parameter of that function. The return type of this function is
+as the `source` parameter of that function.
-a `Container` type which just prints some general information on the resulting
-container when called this way.
-
-```
-_type: Container
-defaultArgs: []
-entrypoint:
-    - helloworld
-mounts: []
-platform: linux/amd64
-user: ""
-workdir: ""
-```
-
-The `Container` has to be consumed by other functions to actually export it to
-some registry or run it. The same is true for other types like `File` and
-`Directory` which also only expose the actual artifacts through 'effectful'
-functions, thus the FP-like feeling. Only 'simple' strings can be exposed on
-the shell. Consequently, pipelining on the shell seems not to be a common
-thing.
-
-Dagger separates the containerized build environment from the host system.
-Unless specifically specified, like with `--source=.`, dagger does not expose
-host resources. This adds to the notion of trying to create reproducible
-actions.
 
 > Camel Case function names in the TS setup are available in Kebab Case on the
 > shell (same applies for Go and Python). This does not only apply to your own
 > declared functions but to all functions available on the returned data types.
 >
 > ```typescript
-> this.build(source).asService().up({ ports: "8080:9000" });
+> this.build(source).asService().up({ ports: "8080:8080" });
 > ```
 >
 > becomes
@@ -101,8 +76,6 @@ actions.
 > ```shell
 > dagger call build --source=. as-service up --ports=8080:9000
 > ```
->
-> Dagger calls this function chaining.
 
 > After running a dagger command the Dagger Engine stays alive as a local
 > container waiting for the next call.
@@ -133,16 +106,15 @@ dagger call security-scan --source=.
 > Python module can be used in a Typescript config. The proper API functions
 > are exposed on the `dag` object.
 
+> Most modules are just thin wrappers around specific images that contain for
+> example some tool and provide convenience functions.
+
 Push the container image to some registry:
 
 ```shell
 dagger call build --source=. publish --address=mtr.devops.telekom.de/...
 ```
 
-This call makes use of the aforementioned chaining capabilities. One could
-create a custom function to chain calls within the config or just chain call in
-a shell call.
-
 ### Deployment to Kubernetes
 
 Dagger at its core does not provide tooling to deploy artifacts to kubernetes
@@ -164,14 +136,10 @@ A critical problem however is the fact that the dagger engine requires running
 in privileged mode, see
 [FAQ](https://docs.dagger.io/faq#can-i-run-the-dagger-engine-as-a-rootless-container).
 Depending on the platform this might be a dealbreaker due to security issues.
-If the platform does not provide a somewhat isolated vm environment that is
+If the platform does not provide a somewhat isolated vm environment, the
-capable of running containers itself (in this case the dagger cli would spawn
+suggested setup includes hosting one or more shared dagger engines within the
-its own instance of the dagger engine), the suggested setup includes hosting
+platform, see the Gitlab CI kubernetes
-one or more shared dagger engines within the platform, see the Gitlab CI
-kubernetes
 [example](https://docs.dagger.io/integrations/gitlab#kubernetes-executor).
-Security concerns of using a shared instance of the dagger engine should be
-investigated if one wants to go down this road.
 
 ## Conclusion