Structure¶
Project consists of a standard structure which includes:
.rkd¶
RiotKit-Do directory, where you can define custom tasks, there are also temporary files and logs stored (ADVANCED)
apps/conf/¶
docker-compose YAML files with definitions of containers, networks and volumes
apps/conf.dev/¶
Same as apps/conf, but enabled only on development environment
apps/profile/¶
Defined service profiles that allows to select services on which you operate in given command (eg. wordpress profile = all instances of wordpress)
apps/healthchecks/¶
RiotKit’s InfraCheck integration, here are placed all of the healthcheck definitions (see section about health and monitoring)
apps/repos-enabled/¶
GIT repositories definitions (see section about applications from external GIT repositories)
apps/www-data/¶
Cloned applications from GIT (see section about applications from external GIT repositories)
containers/¶
Configuration data mounted via bind-mount to inside containers (should be read-only and versioned by GIT)
data/¶
Bind-mounted volume storage for containers, only data that is generated dynamically by containers is stored there.
Example use cases:
- Database data eg. /var/lib/mysql
- Generated SSL certificates storage
- NGINX generated configurations
hooks.d/¶
Scripts that are executed at given time in the Harbor lifecycle (eg. pre-start, post-start, pre-upgrade, …) See section about hooks.
hooks.d/
hooks.d/pre-upgrade
hooks.d/(...)
hooks.d/post-start
Keeping standards¶
KISS - keep it simple stupid
By keeping standards in your project you make sure, that any person that joins your project or a contributor could be satisfied with Harbor documentation. Any outstanding solutions would require you to create extra documentation in your project.