dudadornelles / hop Goto Github PK

possibly using 'backup backends' to define a bit of how/where. There has to be some sort of interface between the provider and the backup_backend so that the provider can hand the data off.

how to proceed? readthedocs.org?

Summary:

• Introduction
• Getting Started
• Plans
• Providers

Some of the methods that are provider specific in HopConfig should be moved to LocalDockerConfig.

HopConfig should only have methods/property that are relevant to hop and not to the providers/auth backends/any future backend.

add initializers for new plans, providers and hop itself. Use cookiecutter

Consider a new command for the future: hop scale. Maybe add the concept of 'initial # of agents' for hop.yml but control the # of agents after that 'hop scale'

For now will just look at how many agents are running and kill the ones with higher index till it matches 'providers.agents.instances'

providers should ideally implement a way to allow for clients to input a auto register key and for other features in https://docs.gocd.io/current/advanced_usage/agent_auto_register.html

either adding a roles field to hop.yml or having a roles.yml in the root.

roles:
  - developer:
    - dev1
    - dev2
    - admin

  - deploy-to-production:
    - dev2

  - admin:
    - admin

Hop should manage the ecs cluester too, it could detect that a cluster is too small and resize itself when running provision.

currently all a provider needs to define is a function provision(hop_config). Should we use actual interfaces (zope-interface)?

Also, what are other methods that the provider has to implement and how do they empower the CLI?

user should be able to define:

• ami
• instance type

the provider should:

• create an ec2 instance with docker in it
• expose the docker api over TCP/TLS
• run the same local_docker plan but using a remote client

==
extras:

• EBS for database volume
• EBS for artifacts
• backup db to s3 job
• route 53 elb and AWS certs for SSL

Silmiar to #6 , but for plans

the agents value in hop.yml should be a more complex object:

agents_prefix: hop-agent # this used to be inside the agents key
agents:
    gocdhop/hop-agent:
        instances: 2
    otherrepo/specialized-agents:
        instances: 1
        tags: specialized

what to do about secrets that the pipelines need at 'runtime'?

options:

• create a comand hop encrypt so users can encrypt values and check them in using the gocd api. Problem is that the gocd encryption algorithm is not safe and that a new gocd installation will have a different cipher. Potential fix would be to have the cipher as an input for hop provision so you could always reuse the same parser.
• reuse admin password to encrypt/decrypt secrets so we can keep them in source control?
• vault?

Also, about secrets needed at provisioning time, what to do about those? env vars could go a long way here for now

Use volumes for the artifact and for the db folder.

Maybe add a flag for this: --force-recreate

As a convenience method we should create a default htpasswd with an admin for users when hop init is called. This requires prompting the user for a password interactively because having passwords in your bash_history is very bad.

Ideally would use semi-decent crypto with https://github.com/danielsomerfield/go-strong-auth-plugin but until we get that working just use the default unsalted SHA.

in case somebody is bringing their own passwd file

currently local_docker provider supports passwd files only, but it must be possible to decouple that and create the concept 'auth backends'