CLI Framework Management
As your policy engine for deployment control, frameworks can be managed in 2 different ways today, through a template YAML file or manual individual commands through Shipa's CLI.
Framework Definition
Frameworks allow you to create policies across networking, RBAC, registry control, and more. These policies are then automatically applied to any application deployed using that specific framework.
Users can leverage configuration files to create and update frameworks dynamically through their pipelines or Shipa's CLI.
When using the CLI, configuration files can be used to create frameworks by using the following command:
shipa framework add template.yaml
The command below can be used to update frameworks from the CLI using a template configuration file:
shipa framework update template.yaml
Below is an example of a framework configuration file:
shipaFramework: framework1
resources:
general:
setup:
default: true
public: true
provisioner: kubernetes
kubeNamespace: ""
plan:
name: shipa-plan
security:
disableScan: true
ignoreComponents:
- busybox
- bash
- curl
- dpkg
ignoreCVES:
- CVE-xxxx-xxxx
- CVE-yyyy-yyyy
access:
append:
- team1
- team2
- teamX
blacklist:
- team3
- teamN
volumes:
- name: volume-1
teamOwner: team1
planName: volume-plan1
capacity: 1G
accessModes: ReadWriteOnce
containerPolicy:
allowedHosts:
- docker.io
nodeSelectors:
terms:
environment: team1
os: linux
strict: true
podAutoScaler:
minReplicas: 1
maxReplicas: 10
targetCPUUtilizationPercentage: 50
disableAppOverride: true
domainPolicy:
allowedCnames:
- "*.example.com"
- "*.acme.bar"
appAutoDiscovery:
appSelector:
- label: app
suffix: ""
networkPolicy:
ingress:
policyMode: allow-all
customRules: []
shipaRules: []
shipaRulesEnabled: []
egress:
policyMode: allow-all
customRules: []
shipaRules: []
shipaRulesEnabled: []
disableAppPolicies: false
shipaNode:
drivers:
- amazonec2
- google
autoScale:
maxContainer: 0
maxMemory: 0
scaleDown: 1.33
rebalance: true
Flags:
Flag | Description |
---|---|
Default | Will the framework be the default framework for application deployment(when none is specified during app create, this framework will be used)? |
Public | Make the framework public for all teams to consume. |
Provisioner | Provisioners are either shipa or kubernetes. If Kubernetes clusters are added to this framework, then kubernetes should be used. Otherwise, it should be used shipa Shipa nodes and Kubernetes clusters cannot coexist in the same framework. |
Plan | Plan which will be assigned to all applications when deployed to this framework. The plan should have been previously created through the shipa plan create command. |
Security | What type of security scan and exceptions, if any, should be performed/allowed on every application deployed using this framework |
Access | Which teams should have access to the framework, or their access revoked |
Volumes | Volumes should be created and made available to applications deployed through this framework. Please note that volumes will be created and attached to the framework but will remain available until they are bound to an application |
containerPolicy | Enforce which docker registry images can be used to deploy applications. allowedHosts: Array of docker registries |
podAutoScaler | Application auto scaling using Kubernetes Horizontal Pod Scaling. minReplicas: The minimum number of pods to run for the app. Required maxReplicas: The maximum number of pods to run for the app. Required targetCPUUtilizationPercentage: The threshold for when to start scaling pods disableAppOverride: Prevent an app from specifying its own configs for the podAutoScaler. Optional, default true |
nodeSelectors | Control app deployment on specific nodes using labels present on the node. terms: Includes array of node labels as key value pairs terms.strict: If enabled, all specified labels must be present on a node or an app cannot be deployed to it. Otherwise, only one of the labels must match for an app to be able to be deployed to a node. Optional, default false |
domainPolicy | Policy to enforce CNAME of applications. allowedCnames : array of cnames as strings |
ShipaNode/Drivers | Which node/cloud providers can be attached to this framework. Please note this is only valid when the provisioner is set to shipa in the Provisioner section. |
ShipaNode/AutoScale | Node autoscale rules for Shipa nodes only |
Adding Frameworks
To create a framework, users should use the Shipa framework add command, as shown below:
shipa framework add <framework> [-p/--public] [-d/--default] [--provisioner <name>] [-f/--force]
Each Shipa node added using the node-add command, by default, belongs to a framework. When creating new applications, a framework must be chosen, which means that all units of the created application will be spawned in nodes belonging to the chosen framework.
Flags:
Flag | Description |
---|---|
-d, --default | (= not set) Marks the framework as the default one(when none is specified during app create, this framework will be used) |
-f, --force | (= false) Force overwrite default framework |
-p, --public | (= false) Make framework public (all teams can use it) |
--provisioner | (= "") Provisioner associated with the framework (empty for default shipa provisioner) |
--allowed-cnames | (=[])CNames permitted for this framework, e.g. *.my-domain.com,another-domain.* |
--node-selectors | (=[])Key value pairs to be used as node selectors |
--plan | The resource plan to use when adding app to this framework |
--provisioner | Provisioner associated to the framework (empty for default kubernetes provisioner) (default "kubernetes") |
--registry | (=[])Allowed container registries |
-s, --strict | (=false) Specifies whether all nodeSelectors must be present on a node |
Manually Updating Framework Attributes
shipa framework update <framework> [--public=true/false] [--default=true/false] [-f/--force]
Updates attribute for a specific framework.
Flags:
Flag | Description |
---|---|
--default | (= not set) Marks the framework as the default one(when none is specified during app creation, this framework will be used) |
-f, --force | (= false) Force framework to be the default. |
--public | (= not set) Make framework public (all teams can use it) |
Manually Adding Teams to Frameworks
After frameworks are created, users can use Shipa's framework constraint set command to add teams to the frameworks that were just created:
shipa framework constraint set framework1 team team1 team2 --append
shipa framework constraint set framework2 team team3 --append
Listing Frameworks
Listing the available frameworks in Shipa can be done by executing the following:
$ shipa framework list
+------------+------+-------------+------------+
| Framework | Kind | Provisioner | Teams |
+------------+------+-------------+------------+
| framework1 | | kubernetes | shipa-team |
+------------+------+-------------+------------+
| dev | | kubernetes | dev |
+------------+------+-------------+------------+
| prod | | kubernetes | prod |
+------------+------+-------------+------------+
| qa | | kubernetes | dev |
+------------+------+-------------+------------+
Removing Frameworks
Frameworks can be removed at any time in Shipa. To do so, users can leverage Shipa's framework remove command:
shipa framework remove framework1
Manually Removing Teams from Frameworks
Administrators can remove one or more teams from frameworks using Shipa's framework constraint set command:
shipa framework constraint set framework1 team team1 --blacklist
shipa framework constraint set framework1 team team1 team2 team3 --blacklist
Updated 11 months ago