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"}}'