github.com/upcmd/up@v0.8.1-0.20230108151705-ad8b797bf04f/tests/functests/c0153.yml (about)

     1  doc_meta: |
     2    folder: user-interaction
     3    title: profile with env vars
     4    head: |
     5      You can use UPcmd to chain the command output as input and choose a task to handle the data processing
     6  
     7    sections:
     8      - title: concept
     9        content: |
    10          So far, we can use an instanceid as context id to select what set of configuration we want to use, nomally they are categorized by global configuration, environment group configuration and individual context instance, for example as below:
    11  
    12          ```
    13          global\_
    14                  |_nonprod
    15                      |_dev
    16                      |_staging
    17                  |_prod
    18                      |_prod
    19          ```
    20  
    21          You could use [ up ngo mytask -i dev ] to do deployment work aginst dev environment
    22  
    23          However these configuration are more like server (backend) configuration. Most of time, we will have some other configurations, they are related to pipeline user input, for example:
    24  
    25          * username
    26          * password(secured)
    27          * flags for build/deployment/workflow to behave differently, eg,
    28              * create db everytime or skip
    29              * a resource id (ec2-instanceid/iam-profile-id/database name etc) as data injection for the workflow
    30          * temporary config entry for manual test
    31  
    32          All these settings are more like a user execution profile rather static and stable server environment configuration, they are the environment variables input from users
    33  
    34          In this case we could classify them all together into an execution profile, for example
    35  
    36          ```
    37          dev(instanceid):
    38          |_ ENV var1
    39          |_ ENV var2
    40          |_ ENV var3
    41  
    42          global\_
    43                  |_nonprod
    44                      |_dev
    45                           \_dev1_test
    46                           \_dev2_test:
    47                           \_dev1_use_memcache:
    48                           \_dev2_no_db_recreat
    49                      |_staging
    50                  |_prod
    51                      |_prod
    52          ```
    53  
    54          By using such a execution profile, the CI/CD tools does not need to handle the multiple environment variable entries and secure variable entries, all these could be handled by UPcmd. To trigger the pipeline, a code push is all needed.
    55  
    56          This turns the audit to a precise git commit history so it is tracable to understand whose code has actually cause the problem
    57  
    58      - title: Best practice
    59        content: |
    60          1. Turn every pipeline settings, eg multiple environment variables to so called evar (evironment var) pair under eprofiles/evars/[key,value]
    61          2. All the other global/group vars, instance vars, runtime global vars are still kept the same ways as they are
    62          3. Normally, for your existing CLI CI/CD build, you would have already got the logic to map the environment vars to your internal programming vars, these will be kept the same as they are
    63          4. The env vars in eprofiles are already takeing effect, they are just like the env vars you setup in your pipeline GUI to take baisc parameters to instruct how the build/deploy will behave
    64  
    65  
    66          * Conventional CI/CD pipeline
    67  
    68          ```
    69          env vars -> pipeline tool via GUI settings -> CLI workflow
    70          ```
    71  
    72          * UPcmd pipeline
    73          ```
    74          UPcmd ==match profile name==>> eprofile/evars => UPcmd managed workflow
    75          ```
    76  
    77      - title: Showcase
    78        content: |
    79          Please note the execution profile extend dev instance, see the differences of the final var merged
    80  
    81          ```
    82          up ngo task -d ./tests/functests -t c0153 -p dev1_use_memcache --configdir=./tests/functests
    83          ```
    84  
    85      - title: Relavant
    86        content: environment variables
    87        refs:
    88          - title: set env var
    89            link: ../../env-vars/c0048/
    90          - title: get env var
    91            link: ../../env-vars/c0046/
    92  
    93  notes:
    94    - add feature of execution profile
    95  
    96  eprofiles:
    97    - name: dev1_use_memcache
    98      instance: dev
    99      evars:
   100        - name: DEPLOY_USER
   101          value: tomhanks
   102        - name: SKIP_CREATE_RDS
   103          value: "yes"
   104        - name: DB_HOST
   105          value: devtest_database.mycompany.local
   106  
   107  scopes:
   108    - name: global
   109      vars:
   110        db_driver: postgres
   111        port: 5432
   112      dvars:
   113        - name: A_GLOBAL_ENV_VAR
   114          value: a_global_env_var
   115          flags:
   116            - envVar
   117  
   118    - name: nonprod
   119      members:
   120        - dev
   121        - staging
   122      vars:
   123        db_host: nonpord_database.test.host
   124        db_port: 8354
   125        db_user: test_db_user
   126        db_password: could_be_encrypted_using_upcmd_too
   127      dvars:
   128        - name: db_password
   129          value: '6HmsmiJIW1PfIXcF4WwOKOMDiL7PstgfKs2aRFajrwY='
   130  
   131    - name: prod
   132      members: [prod]
   133      vars:
   134        host_alias: prod
   135  
   136    - name: dev
   137      vars:
   138        host_alias: dev
   139      dvars:
   140        - name: db_host
   141          value: '{{ env "DB_HOST" |default "nonpord_database.test.host" }}'
   142        - name: A_DEV_ENV_VAR
   143          value: '{{ env "A_GLOBAL_ENV_VAR" |default "A_GLOBAL_ENV_VAR_NOT_LOCATED" }}'
   144  
   145    - name: staging
   146      vars:
   147        host_alias: staging
   148  
   149    - name: prod
   150      vars:
   151        host_alias: prod
   152        db_host: pord_database.proddb.host
   153        db_user: prod_db_user
   154      dvars:
   155        - name: db_password
   156          value: 'prod_encrypte_aes'
   157  
   158  dvars:
   159    - name: db_hostname
   160      value: '{{.host_alias}}.myapp.com'
   161    - name: db_url
   162      value: 'jdbc:{{.db_driver}}://{{.db_hostname}}:{{.db_port}}/test?user={{.db_user}}&password={{.db_password}}&ssl=true'
   163  
   164  tasks:
   165    -
   166      name: task
   167      task:
   168  
   169        -
   170          func: cmd
   171          do:
   172            - name: inspect
   173              cmd:
   174                - exec_vars
   175            -
   176              name: assert
   177              cmd:
   178                - '{{eq .A_GLOBAL_ENV_VAR "a_global_env_var"}}'
   179                - '{{eq .A_DEV_ENV_VAR "a_global_env_var"}}'
   180                - '{{eq .db_host "devtest_database.mycompany.local"}}'
   181                - '{{eq .db_url "jdbc:postgres://dev.myapp.com:8354/test?user=test_db_user&password=6HmsmiJIW1PfIXcF4WwOKOMDiL7PstgfKs2aRFajrwY=&ssl=true"}}'