Custom Rules

[cyberndj]

Howdy,
I'm currently running docker swarm....
Is it possible to create some custom rules? Example, each service in a stack should contain certain labels (for traefik in my case).

Ex. Each Service should contain ether one of the following items

deploy:
  labels:
    traefik.enable: 'false'

-or-

deploy:
  labels:
    traefik.http.routers.<$service>.rule: <$aString>
    traefik.http.services.<$service>.loadbalancer.server.port: <$number>

where:
<$service> should be the same
<$aString> would be any string value
<$number> would be any number between 1 and 65535

[zavoloklom]

@cyberndj Hi!

At the moment, dclint doesn’t support user-defined rules out of the box. I’ve been thinking about how to allow custom rule definitions, but haven’t yet landed on a simple and flexible solution that balances usability and maintainability.

Do you have any ideas or preferences on how you'd like to define such rules?

[cyberndj]

Howdy,

I think that a starting point would be that a 'node' must/must-not exist/begins-with/contains (maybe other conditionals/hopefully my terminology is correct). I think block sections...but there is also key:value pairs for the definitions. All done to proper syntax...

.dclint-custom-rules.yml

custom-definitions:
  info: 'fail'   # ie, what to do if a condition is not met. 'Pass' 'Warning' 'Fail' etc
  node-must-exist: 
    {     # All three nodes 'must-exist'
          'image',
          'traefik.enable',
          'traefik.http.routers'
    }
  node-not-exists:
    { 
      'traefik.enable',
      'build'
    }
  node-begins:
    {
      'traefik.enable'
    }
  node-contains:
    condition: 'and'      # other option could be 'or', defaults to 'and'
    {            # Define nodes and their values definition option.
      enable: 
        key: "traefik.enable"
        value: 'true' 
      homepage: 
        key: "homepage.description"
        value: 'traefik'
    }
  node-conditional:
    condition: 'or'
    node-contains:
      {
        traefik.enable: 'false',
      },
    node-begins:
      {
        'traefik.http.routers',
        'traefik.http.service'
      }

[cyberndj]

Thought about it a bit more....a bit of a different way to write it to make it a bit cleaner (for me at least).

.dclint-custom-rules.yml

custom-rules:
  <name of rule>:                                                                                                   # Name of the rule
    description: <a text description of what the rule does. will show up in logs.> # Optional. Blank defaults to rule name
    errors: <Pass | Warning | Fail >                                                                          # Optional. Defaults to Fail
    action: < exists | not-exists | begins | contains | conditional >                          # Optional. Defaults to exists
    condition: < and | or >                                                                                      # Optional. Defaults to 'and'
    service: < a specific or list of service/container-names >                                 # Optional. Defaults to 'all'
    nodes:                                                                                                                # Required, Except for a 'conditional'
      - traefik.enable
      - image
      - homepage.description

  restarts:
    nodes:
      - restart-policy

  rule-2:
    action: contains
    nodes:
      command: "echo Hello World"
      traefik.enable: 'true'

  <conditional-rule>:
    description: Example of how to do complex conditional statements
    action: conditional
    condition: or
    rules:                      # 'nodes' are removed in favor of a list of 'rules'
      - restarts
      - rule-2
      - <name of rule>    

[janitor-of-code]

I'd be interested in this feature too, although it's not very important for our workflow.

My use case would be to forbid container_name: since in our infrastructure that's something portainer shall do.
That way I don't have to mention it in reviews and let our pipelines do the yelling.

I quite like the second suggestion it looks intuitive to me.
Also the idea of having a rule of rules sounds neat.

(ofc all that sounds like a lot of refactoring work)

---

for completeness: I assume my rule would look like that:

custom-rules:
  no-container-name
    description:
    errors: Warning
    action: not-exists
    nodes:
      - container_name