GitBook: [#36] docs: minor fix

README.md

@@ -0,0 +1,19 @@
+# dyrector.io documentation
+
+dyrector.io is an open-source deployment platform that helps software developer teams manage releases & deployments easily and efficiently. While non-specialists are enabled to manage these processes in a simplified, self-service manner, specialists can deploy and manage containerized apps faster through the platform. Find out what you can do with dyrector.io!
+
+**You can find dyrector.io's GitHub repository** [**here**](https://github.com/dyrector-io/dyrectorio/)**. Feel free to contribute!**
+
+{% hint style="info" %}
+This documentation is in the works along with our product’s development. In case you’ve got feedback regarding the docs, please reach out to us at [hello@dyrector.io](mailto:hello@dyrector.io). **Contributions are always welcome.**
+{% endhint %}
+
+**If you want to cut to the chase, go to** [**Tutorials**](broken-reference) **to see how you can execute deployments with dyrector.io.**
+
+### Concept
+
+**Life isn’t about release management.** Why should teams focus so much of their precious time and effort on it when things can be simpler?
+
+dyrector.io is for you if you’d like to shift your team’s focus from repeatable steps of multi-instance deployments to delivering value to your users. And when a deployment is successful or any error occurs, the team gets notified so they can react as soon as possible.
+
+While dyrector.io enables non-technical staff members to help with certain tasks, it’s also useful to reduce time technical staff spend on deployment and system administration.

SUMMARY.md

@@ -0,0 +1,51 @@
+# Table of contents
+
+* [dyrector.io documentation](README.md)
+
+## Basics
+
+* [Where to start](docs/basics/where-to-start.md)
+* [How it works](docs/basics/how-it-works.md)
+
+## Get started
+
+* [Overview](docs/get-started/overview.md)
+* [Use cases](docs/get-started/use-cases.md)
+* [Components](docs/get-started/components.md)
+* [Core functionality](docs/get-started/core-functionality.md)
+
+## Features
+
+* [Multi-Instance Deployments](docs/features/multi-instance-deployments.md)
+* [Configuration management](docs/features/configuration-management.md)
+* [Monitoring](docs/features/monitoring.md)
+* [Audit log](docs/features/audit-log.md)
+
+## Tutorials
+
+* [Onboarding](docs/tutorials/onboarding.md)
+* [Add your Registry](docs/tutorials/add-your-registry/README.md)
+  * [Add V2 Registry](docs/tutorials/add-your-registry/add-v2-registry.md)
+  * [Add Docker Hub Registry](docs/tutorials/add-your-registry/add-docker-hub-registry.md)
+  * [Add GitHub Registry](docs/tutorials/add-your-registry/add-github-registry.md)
+  * [Add GitLab Registry](docs/tutorials/add-your-registry/add-gitlab-registry.md)
+  * [Add Google Registry](docs/tutorials/add-your-registry/add-google-registry.md)
+* [Register your Node](docs/tutorials/register-your-node.md)
+* [Create your Product](docs/tutorials/create-your-product/README.md)
+  * [Create a Simple Product](docs/tutorials/create-your-product/create-a-simple-product.md)
+  * [Create a Complex Product](docs/tutorials/create-your-product/create-a-complex-product/README.md)
+    * [Create a Rolling Version](docs/tutorials/create-your-product/create-a-complex-product/create-a-rolling-product.md)
+    * [Create an Incremental Product](docs/tutorials/create-your-product/create-a-complex-product/create-an-incremental-product.md)
+    * [Add a version to your Complex Product](docs/tutorials/create-your-product/create-a-complex-product/add-a-version-to-your-complex-product.md)
+* [Deploy your Product](docs/tutorials/deploy-your-product.md)
+* [Create Chat Notifications](docs/tutorials/create-chat-notifications.md)
+
+## Learn more
+
+* [Changelog](docs/learn-more/changelog.md)
+* [Roadmap](docs/learn-more/roadmap/README.md)
+  * [Features in progress](docs/learn-more/roadmap/features-in-progress.md)
+  * [Integrations in progress](docs/learn-more/roadmap/integrations-in-progress.md)
+* [Pricing](docs/learn-more/pricing.md)
+* [FAQ](docs/learn-more/faq.md)
+* [Community](docs/learn-more/community.md)

docs/basics/how-it-works.md

@@ -0,0 +1,27 @@
+# How it works
+
+### Architecture
+
+You can use dyrector.io in a cloud-hosted or a self-hosted way.
+
+#### Cloud-hosted
+
+![By using free and paid packages, you're getting access to dyrector.io hosted by us on the cloud.](../.gitbook/assets/dyrector-io-cloud-hosted-architecture-dark.png)
+
+By using cloud-hosted dyrector.io, you’re able to register dyrector.io’s agent to your Nodes. When adding a Node, you can select whether you’d like to use Docker API or Kubernetes API on it.
+
+To add a Node, you need to run the one-liner script generated by us in your Node’s terminal. The one-liner script will run a script that'll install dyrector.io's agent to your Node.
+
+This is how dyrector.io will operate if you decide to use our free or paid packages. Learn more about our packages [**here**](https://dyrector.io/pricing).
+
+#### Self-hosted
+
+![](../.gitbook/assets/dyrector-io-self-hosted-architecture-dark.png)
+
+Similar to the cloud-hosted way, you can use self-hosted dyrector.io with Docker or Kubernetes. Only difference is it’s up to you where dyrector.io will run.
+
+If you don’t want to configure your own dyrector.io, check our packages to see one that’ll fit your needs.
+
+{% hint style="success" %}
+One of the most important benefits of self-hosted dyrector.io is that you can use the environment where you run dyrector.io as an instant test environment.
+{% endhint %}

docs/basics/where-to-start.md

@@ -0,0 +1,15 @@
+# Where to start
+
+{% hint style="info" %}
+**If you want to cut to the chase, go to** [**Tutorials**](broken-reference) **to see how you can execute deployments with dyrector.io.**
+{% endhint %}
+
+Check out the [**Components**](../get-started/components.md) section for a basic description of entities and components of dyrector.io’s workflow. To better understand how your teammates will interact with dyrector.io, take a look at the [**Roles in dyrector.io’s workflow**](../get-started/overview.md) part.
+
+Find out how you can use dyrector.io under the [**Tutorials**](broken-reference) section where you can see through how you can use each function step-by-step.
+
+Read the [**Features**](broken-reference) section to find out about use cases and best practices of dyrector.io’s features. If you're curious about upcoming features and integrations, check [**Roadmap**](../learn-more/roadmap/).
+
+{% hint style="success" %}
+If you have any questions about dyrector.io, check the [**FAQ**](../learn-more/faq.md) section. Join our community at the channels included in the [**Community**](../learn-more/community.md) section.
+{% endhint %}

docs/features/audit-log.md

@@ -0,0 +1,5 @@
+# Audit log
+
+Keep track of the actions your teammates execute with dyrector.io. This way if a malfunction occurs, you can understand if it was due to a specific action or an outside factor.
+
+We monitor user ID, time and unsensitive data related to actions on dyrector.io. Audit logging on our platform only monitors actions executed by dyrector.io users.

docs/features/configuration-management.md

@@ -0,0 +1,51 @@
+# Configuration management
+
+Configurations can be all over the place without a single source of truth when left unmanaged for long periods of time. The more configurations you need to deal with, the more likely you’ll lose track of them. dyrector.io can be used as single source of truth for all of your configurations, while being able to add, remove or modify configurations directly or via the JSON editor.
+
+Every configuration you specify will remain stored after any modification or deletion to ensure you won’t have to spend time again defining already specified configurations.
+
+### How is it better than using a Git repository?
+
+Git repositories containing the configurations of your microservice architecture can be all over the place because one repo won’t cover all the configurations for all the images & components in your architecture. dyrector.io substitutes Git repos by bringing every variable that belong to a specific Product in one place.
+
+#### Use cases
+
+* **Think ahead:** designing is the first step towards efficient and secure configuration management. Go through your organization’s structure, consider privileges and access points. This step is crucial for more efficient configuration management.
+* **Configuration roll back:** if it turns out the new configuration variables need to be reworked to maintain uptime of your application, you can roll back the last functioning ones.
+* **In progress – Bundled configurations:** instead of specifying the same configurations one by one to each component, you can apply variables to multiple components with one click by bundling them up.
+
+### Configuration customization
+
+You're able to define configurations for both [**Product images**](../tutorials/create-your-product/) and [**Deployments**](../tutorials/deploy-your-product.md). Variables that belong to images can be overwritten by Deployment variables.
+
+![](../.gitbook/assets/configurations-json.jpg)
+
+#### JSON
+
+You're also able to customize your configuration in JSON format, for easier copying. The variables by default are the following:
+
+The result should look like this:
+
+<pre class="language-json5"><code class="lang-json5">{
+  // Running application container name.
+  "name": "mysql",
+  // Path/volume bindings for containers.
+  "mounts": ["data|/var/lib/mysql"],
+<strong>  // Maps an internal 80 to external 8080, external refers to the host's port.
+</strong>  "ports": [
+    {
+      "internal": 80,
+      "external": 8080
+    }
+  ],
+  // Docker specific networkMode configuration, can be host or none.
+  "networkMode": "none",
+  // Environment variables used to configure application behavior.
+  // Tribute to https://12factor.net
+  "environment": {},
+  // WIP (not available yet) configure container behavior based on annotations.
+  "capabilities": {},
+  // If managed ingress is enabled on node (traefik or ingress is deployed)
+  // ingress could be generated here. This is for http traffic for now.
+  "expose": {"public": true, "tls": true}
+}</code></pre>

docs/features/monitoring.md

@@ -0,0 +1,5 @@
+# Monitoring
+
+You might have felt like deploying your product is a shot in the dark before. dyrector.io allows teams to check on deployment statuses and infrastructure components.
+
+Sometimes it’s difficult for developers and ops teams to figure out which part of their product runs on what environment. On dyrector.io all this information is available, so you won’t have to investigate your applications and infrastructure.

docs/features/multi-instance-deployments.md

@@ -0,0 +1,9 @@
+# Multi-Instance Deployments
+
+Deploying the same application to several environments is demanding, boring and repetitive. Human presence makes it risky, too. That’s why reducing the steps of multi-instance deployments are crucial for efficiency.
+
+With dyrector.io, you can trigger multi-instance deployments by assembling your product out of the desired images and selecting the Nodes you want the app to be deployed to. All this without coding. To see how you can do these steps, check the [**Tutorials**](broken-reference) where we lead you through the process step-by-step.
+
+#### Use cases
+
+* **In progress – Bundled configurations:** without specifying the same configurations again and again, you can specify bundled variables in an instant. Learn more about them under the Configuration management tab of Features.

docs/get-started/components.md

@@ -0,0 +1,47 @@
+---
+description: >-
+  To better understand how you’ll be able to manage your applications in
+  dyrector.io, there are certain components – entities and concepts – within
+  dyrector.io that need to be cleared.
+---
+
+# Components
+
+### Node
+
+Nodes are deployment targets. They can be Docker, Kubernetes, even on-premises environments; it really depends on your needs. Specifying at least one Node is a basic requirement of both using dyrector.io and deploying your application. For this reason, we suggest this should be the first step you do after the first login.
+
+### **Team**
+
+A group of users working on the same project. On your first login you must define a team, to which you can invite your teammates’ profiles. Teams can have multiple Nodes and Registries.
+
+### Profile
+
+Your user profile on dyrector.io.
+
+### Audit log
+
+Audit logs collect team activity. It lists executed actions, the users who initiated them and the time of when the actions happened.
+
+Logs are assigned to teams. One profile can belong to multiple teams.
+
+### Registry
+
+Registry is the place where you can store your images. You can use any Docker Registry API V2 compatible Registry with dyrector.io, and besides them GitHub and GitLab Registries. Docker Hub Library is available to every user by default.
+
+### Product
+
+Products are the applications you’ll manage in dyrector.io. There are two types of Products.
+
+![The differences between types of Products in dyrector.io.](<../.gitbook/assets/product types\_dark.png>)
+
+* **Simple:** these Products have only one version and cannot be rolled back. These are mostly useful for testing purposes, because simple Products come without versions.
+* **Complex:** complex Products have two types of versions: Rolling and Incremental.
+  * **Rolling Versions:** rolling versions are similar to simple Products except they’re perfect for continuous delivery. They’re always mutable but contrary to incremental Products they aren’t hierarchic and lack a version number.
+  * **Incremental Versions:** incremental Products are hierarchical. They can have a child version and once a deployment is successful, the deployed versions, the environment variables, and the deployed images can never be modified. This guarantees you’re able to roll back the deployed version and reinstate the last functional one if any error occurs to avoid downtime.
+
+Regardless of the type of product you want to manage, you can pick the images you want to include in the managed version and also specify configurations that belong to them.
+
+### Deployment
+
+After assembling your product, you can trigger a deployment to a Node. Users can assign environment and configuration variables to the deployments.

docs/get-started/core-functionality.md

@@ -0,0 +1,21 @@
+# Core functionality
+
+This section's goal is to introduce dyrector.io's capabilities and how organizations can make the most out of using it. **If you're reading the docs to find out how to execute deployments on the platform, head to the** [**Tutorials**](broken-reference)**.**
+
+The purpose of using dyrector.io is to reduce time and budget spent on release management. To achieve this, dyrector.io helps you with the following features.
+
+### [Features](broken-reference)
+
+* **Multi-instance deployment –** Trigger deployments of the same application to multiple environments from one place using the same or various configurations.
+* **Instant test environments –** Seamless testing whenever your team wants to test the application, without waiting for a SysAdmin to set up an environment.
+* **Configuration management –** You can manage your configurations in one place on dyrector.io. No need to look for different places where you’re able to access and work with them.\
+  **In progress:** Specify bundled configuration variables instead of going through them one-by-one, repeatedly.
+* **Monitoring –** Get notified if a deployment is successful or any failure occurred. Gain better understanding on how your infrastructure and applications perform.
+* **Audit log –** We’re creating activity logs so you can follow up on what actions were executed by your team. This can be useful when teams hold retrospective meetings.
+
+#### [Features in progress](../learn-more/roadmap/features-in-progress.md)
+
+* **Changelogs –** You're able to create changelogs at ease based on commit messages with the help of Conventional Commits, so your team understands the purpose of new versions. This simplifies communication between departments who work on the product and outsiders, for example decision-makers. The generated changelogs can be sent out via e-mail or any chatbot integration.
+* **Secret management –** Store and manage sensitive data with our Vault integration powered by Hashi Corp.
+* **RBAC – Role based access control** lets you distribute privileges based on their responsibilities to your teammates. This is important to prevent any wrongdoing in case a user profile gets corrupted.
+* **ChatOps solutions –** Get automated messages about events and actions that occur on your infrastructure.

docs/get-started/overview.md

@@ -0,0 +1,41 @@
+---
+description: >-
+  To better understand responsibilities revolving dyrector.io, read how each
+  stakeholder in your SDLC interacts with the platform.
+---
+
+# Overview
+
+{% hint style="info" %}
+If you want to learn how you can deploy applications with dyrector.io, check the [**Tutorials**](broken-reference) section. However, it's important to go through the Get Started section for successful adoption of dyrector.io.
+{% endhint %}
+
+There are four roles involved in dyrector.io’s workflow. These are Developers, Release Managers, SysAdmins / DevOps Engineers and Stakeholders. Based on their responsibilities, they interact differently with dyrector.io.
+
+### General use case of dyrector.io
+
+In the flowchart below you can see how dyrector.io fits into Software Development Lifecycle (SDLC).
+
+* Your Developer teammate commits to a Registry, which your Release Manager teammate gets notified about.
+* The Release Manager or any stakeholder can set up a testing environment self-service to validate the new version’s functionality.
+* After successful testing, the Release Manager or any stakeholder can trigger the deployment of the new version.
+
+In case of an emergency, specialist or non-specialist stakeholders can intervene on an abstract level via dyrector.io to avoid downtime for a temporary fix.
+
+![Flowchart of how each stakeholder and component in the SDLC interacts with dyrector.io.](../.gitbook/assets/dyrector-io-workflow-roles-dark.png)
+
+### Developers / Engineers
+
+Developers commit to either a 3rd party or a private Registry. The image is then built automatically – this process can be triggered via dyrector.io, as well, if necessary. Once the image is built, it’s available to push to the Registry.
+
+### Release Managers
+
+In this case, Release Manager is a superficial role. They can be project managers, billing coordinators, basically anyone who interacts with dyrector.io and is responsible of making sure the corresponding version is deployed to the users. Release Managers have access to the Products, and they can deploy them to the Nodes with a single click. They’re able to validate the Product’s functionality and monitor the development progress. Besides these, they can create release notes so everyone can understand how a certain version or product is different.
+
+### SysAdmins / DevOps Engineers
+
+DevOps engineers configure the components that make up the workflow, including the Nodes, pipelines and services.
+
+### Product Owners, Project Managers, Stakeholders
+
+Stakeholders have access to Product information, but they can’t execute any actions regarding them.