4.2.2. Configuration du déploiement

Voir aussi

L’architecture de la solution logicielle, les éléments de dimensionnement ainsi que les principes de déploiement sont définis dans le DAT.

4.2.2.1. Fichiers de déploiement

Les fichiers de déploiement sont disponibles dans la version VITAM livrée dans le sous-répertoire deployment . Concernant l’installation, ils consistent en 2 parties :

  • les playbook ansible de déploiement, présents dans le sous-répertoire ansible-vitam, qui est indépendant de l’environnement à déployer ; ces fichiers ne sont normalement pas à modifier pour réaliser une installation.
  • l’arborescence d’inventaire ; des fichiers d’exemple sont disponibles dans le sous-répertoire environments. Cette arborescence est valable pour le déploiement d’un environnement, et est à dupliquer lors de l’installation d’environnements ultérieurs. Les fichiers qui y sont contenus doivent être adaptés avant le déploiement, comme il est expliqué dans les paragraphes suivants.

4.2.2.2. Informations « plate-forme »

4.2.2.2.1. Inventaire

Pour configurer le déploiement, il est nécessaire de créer dans le répertoire environments un nouveau fichier d’inventaire (dans la suite, ce fichier sera communément appelé hosts.<environnement>). Ce fichier doit être basé sur la structure présente dans le fichier hosts.example (et notamment respecter scrupuleusement l’arborescence des groupes ansible) ; les commentaires dans ce fichier donnent les explications permettant l’adaptation à l’environnement cible :

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
# Group definition ; DO NOT MODIFY
[hosts]

# Group definition ; DO NOT MODIFY
[hosts:children]
vitam
reverse
library
hosts-dev-tools
ldap


########### Tests environments specifics ###########

# EXTRA : Front reverse-proxy (test environments ONLY) ; add machine name after
[reverse]
# optional : after machine, if this machine is different from VITAM machines, you can specify another become user
# Example
# vitam-centos-01.vitam ansible_ssh_user=centos

########### Extra VITAM applications ###########

[ldap] # Extra : OpenLDAP server
# LDAP server !!! NOT FOR PRODUCTION !!! Test only

[library]
# TODO: Put here servers where this service will be deployed : library

[hosts-dev-tools]
# TODO: Put here servers where this service will be deployed : mongo-express, elasticsearch-head

[elasticsearch:children] # EXTRA : elasticsearch
hosts-elasticsearch-data
hosts-elasticsearch-log

########### VITAM services ###########

# Group definition ; DO NOT MODIFY
[vitam:children]
zone-external
zone-access
zone-applicative
zone-storage
zone-data
zone-admin


##### Zone externe


[zone-external:children]
hosts-ihm-demo
hosts-cerebro
hosts-ihm-recette

# If you don't need consul for ihm-demo, you can set this var:
# consul_disabled=true
[hosts-ihm-demo]
# TODO: Put here servers where this service will be deployed : ihm-demo

[hosts-ihm-recette]
# TODO: Put here servers where this service will be deployed : ihm-recette (extra feature)

[hosts-cerebro]
# TODO: Put here servers where this service will be deployed : vitam-elasticsearch-cerebro


##### Zone access

# Group definition ; DO NOT MODIFY
[zone-access:children]
hosts-ingest-external
hosts-access-external

[hosts-ingest-external]
# TODO: Put here servers where this service will be deployed : ingest-external


[hosts-access-external]
# TODO: Put here servers where this service will be deployed : access-external


##### Zone applicative

# Group definition ; DO NOT MODIFY
[zone-applicative:children]
hosts-ingest-internal
hosts-processing
hosts-batch-report
hosts-worker
hosts-access-internal
hosts-metadata
hosts-functional-administration
hosts-logbook
hosts-workspace
hosts-storage-engine
hosts-security-internal

[hosts-security-internal]
# TODO: Put here servers where this service will be deployed : security-internal


[hosts-logbook]
# TODO: Put here servers where this service will be deployed : logbook


[hosts-workspace]
# TODO: Put here servers where this service will be deployed : workspace


[hosts-ingest-internal]
# TODO: Put here servers where this service will be deployed : ingest-internal


[hosts-access-internal]
# TODO: Put here servers where this service will be deployed : access-internal


[hosts-metadata]
# TODO: Put here servers where this service will be deployed : metadata


[hosts-functional-administration]
# TODO: Put here servers where this service will be deployed : functional-administration


[hosts-processing]
# TODO: Put here servers where this service will be deployed : processing


[hosts-storage-engine]
# TODO: Put here servers where this service will be deployed : storage-engine

[hosts-batch-report]
# TODO: Put here servers where this service will be deployed : batch-report

[hosts-worker]
# TODO: Put here servers where this service will be deployed : worker
# Optional parameter after each host : vitam_worker_capacity=<integer> ; please refer to your infrastructure for defining this number ; default is ansible_processor_vcpus value (cpu number in /proc/cpuinfo file)


##### Zone storage

[zone-storage:children] # DO NOT MODIFY
hosts-storage-offer-default
hosts-mongodb-offer

[hosts-storage-offer-default]
# TODO: Put here servers where this service will be deployed : storage-offer-default
# LIMIT : only 1 offer per machine and 1 machine per offer
# Mandatory param for each offer is offer_conf and points to offer_opts.yml & vault-vitam.yml (with same tree)
# hostname-offre-1.vitam offer_conf=offer-swift-1
# for filesystem
# hostname-offre-2.vitam offer_conf=offer-fs-1

[hosts-mongodb-offer:children]
hosts-mongos-offer
hosts-mongoc-offer
hosts-mongod-offer

[hosts-mongos-offer]
# WARNING : DO NOT COLLOCATE WITH [hosts-mongos-data]
# TODO: put here servers where this service will be deployed : mongos cluster for storage offers
# Mandatory param : mongo_cluster_name : name of the cluster (should exist in the offer_conf configuration)
# Example (for a more complete one, see the one in the group hosts-mongos-data) :
# vitam-mongo-swift-offer-01   mongo_cluster_name=offer-swift-1
# vitam-mongo-swift-offer-02   mongo_cluster_name=offer-swift-1
# vitam-mongo-fs-offer-01      mongo_cluster_name=offer-fs-1
# vitam-mongo-fs-offer-02      mongo_cluster_name=offer-fs-1

[hosts-mongoc-offer]
# WARNING : DO NOT COLLOCATE WITH [hosts-mongoc-data]
# TODO: put here servers where this service will be deployed : mongoc cluster for storage offers
# Mandatory param : mongo_cluster_name : name of the cluster (should exist in the offer_conf configuration)
# Optional param : mandatory for 1 node of the shard, some init commands will be executed on it
# Optional param : mongo_arbiter=true : the node will be only an arbiter ; do not add this paramter on a mongo_rs_bootstrap node
# Example :
# vitam-mongo-swift-offer-01   mongo_cluster_name=offer-swift-1                       mongo_rs_bootstrap=true
# vitam-mongo-swift-offer-02   mongo_cluster_name=offer-swift-1
# vitam-swift-offer            mongo_cluster_name=offer-swift-1                       mongo_arbiter=true
# vitam-mongo-fs-offer-01      mongo_cluster_name=offer-fs-1                          mongo_rs_bootstrap=true
# vitam-mongo-fs-offer-02      mongo_cluster_name=offer-fs-1
# vitam-fs-offer               mongo_cluster_name=offer-fs-1                          mongo_arbiter=true

[hosts-mongod-offer]
# WARNING : DO NOT COLLOCATE WITH [hosts-mongod-data]
# TODO: put here servers where this service will be deployed : mongod cluster for storage offers
# Mandatory param : mongo_cluster_name : name of the cluster (should exist in the offer_conf configuration)
# Mandatory param : id of the current shard, increment by 1 from 0 to n
# Optional param : mandatory for 1 node of the shard, some init commands will be executed on it
# Optional param : mongo_arbiter=true : the node will be only an arbiter ; do not add this paramter on a mongo_rs_bootstrap node
# Example :
# vitam-mongo-swift-offer-01   mongo_cluster_name=offer-swift-1    mongo_shard_id=0                   mongo_rs_bootstrap=true
# vitam-mongo-swift-offer-02   mongo_cluster_name=offer-swift-1    mongo_shard_id=0
# vitam-swift-offer            mongo_cluster_name=offer-swift-1    mongo_shard_id=0                   mongo_arbiter=true
# vitam-mongo-fs-offer-01      mongo_cluster_name=offer-fs-1       mongo_shard_id=0                   mongo_rs_bootstrap=true
# vitam-mongo-fs-offer-02      mongo_cluster_name=offer-fs-1       mongo_shard_id=0
# vitam-fs-offer               mongo_cluster_name=offer-fs-1       mongo_shard_id=0                   mongo_arbiter=true

##### Zone data

# Group definition ; DO NOT MODIFY
[zone-data:children]
hosts-elasticsearch-data
hosts-mongodb-data

[hosts-elasticsearch-data]
# TODO: Put here servers where this service will be deployed : elasticsearch-data cluster
# 2 params available for huge environments (parameter to be declared after each server) :
#    is_data=true/false
#    is_master=true/false
#    other options are not handled yet
# defaults are set to true, if undefined. If defined, at least one server MUST be is_data=true
# Examples :
# server1 is_master=true is_data=false
# server2 is_master=false is_data=true
# More explanation here : https://www.elastic.co/guide/en/elasticsearch/reference/5.6/modules-node.html


# Group definition ; DO NOT MODIFY
[hosts-mongodb-data:children]
hosts-mongos-data
hosts-mongoc-data
hosts-mongod-data

[hosts-mongos-data]
# WARNING : DO NOT COLLOCATE WITH [hosts-mongos-offer]
# TODO: Put here servers where this service will be deployed : mongos cluster
# Mandatory param : mongo_cluster_name=mongo-data  ("mongo-data" is mandatory)
# Example :
# vitam-mdbs-01   mongo_cluster_name=mongo-data
# vitam-mdbs-01   mongo_cluster_name=mongo-data
# vitam-mdbs-01   mongo_cluster_name=mongo-data

[hosts-mongoc-data]
# WARNING : DO NOT COLLOCATE WITH [hosts-mongoc-offer]
# TODO: Put here servers where this service will be deployed : mongoc cluster
# Mandatory param : mongo_cluster_name=mongo-data  ("mongo-data" is mandatory)
# Optional param : mandatory for 1 node of the shard, some init commands will be executed on it
# Example :
# vitam-mdbc-01   mongo_cluster_name=mongo-data                     mongo_rs_bootstrap=true
# vitam-mdbc-01   mongo_cluster_name=mongo-data
# vitam-mdbc-01   mongo_cluster_name=mongo-data

[hosts-mongod-data]
# WARNING : DO NOT COLLOCATE WITH [hosts-mongod-offer]
# TODO: Put here servers where this service will be deployed : mongod cluster
# Each replica_set should have an odd number of members (2n + 1)
# Reminder: For Vitam, one mongodb shard is using one replica_set
# Mandatory param : mongo_cluster_name=mongo-data ("mongo-data" is mandatory)
# Mandatory param : id of the current shard, increment by 1 from 0 to n
# Optional param : mandatory for 1 node of the shard, some init commands will be executed on it
# Example:
# vitam-mdbd-01  mongo_cluster_name=mongo-data   mongo_shard_id=0  mongo_rs_bootstrap=true
# vitam-mdbd-02  mongo_cluster_name=mongo-data   mongo_shard_id=0
# vitam-mdbd-03  mongo_cluster_name=mongo-data   mongo_shard_id=0
# vitam-mdbd-04  mongo_cluster_name=mongo-data   mongo_shard_id=1  mongo_rs_bootstrap=true
# vitam-mdbd-05  mongo_cluster_name=mongo-data   mongo_shard_id=1
# vitam-mdbd-06  mongo_cluster_name=mongo-data   mongo_shard_id=1

###### Zone admin

# Group definition ; DO NOT MODIFY
[zone-admin:children]
hosts-consul-server
hosts-kibana-data
log-servers
hosts-elasticsearch-log

[hosts-consul-server]
# TODO: Put here servers where this service will be deployed : consul

[hosts-kibana-data]
# TODO: Put here servers where this service will be deployed : kibana (for data cluster)

[log-servers:children]
hosts-kibana-log
hosts-logstash


[hosts-kibana-log]
# TODO: Put here servers where this service will be deployed : kibana (for log cluster)

[hosts-logstash]
# TODO: Put here servers where this service will be deployed : logstash


[hosts-elasticsearch-log]
# TODO: Put here servers where this service will be deployed : elasticsearch-log cluster

########### Global vars ###########

[hosts:vars]

# ===============================
# VITAM
# ===============================

# Declare user for ansible on target machines
ansible_ssh_user=
# Can target user become as root ? ; true is required by VITAM (usage of a sudoer is mandatory)
ansible_become=true

# Related to Consul ; apply in a table your DNS server(s)
# Example : dns_servers=["8.8.8.8","8.8.4.4"]
dns_servers=

# Vitam tenants to create
vitam_tenant_ids=[0,1,2]
vitam_tenant_admin=1

### Logback configuration ###
# Days before deleting logback log files (java & access logs for vitam components)
days_to_delete_logback_logfiles=

# Configuration for Curator
#	Days before deletion on log management cluster; 365 for production environment
days_to_delete_logstash_indexes=
#	Days before closing "old" indexes on log management cluster; 30 for production environment
days_to_close_logstash_indexes=

# Define local Consul datacenter name
vitam_site_name=prod-dc1
# EXAMPLE : vitam_site_name = prod-dc1
# check whether on primary site (true) or secondary (false)
primary_site=true


# ===============================
# EXTRA
# ===============================
# Environment (defines title in extra on reverse homepage). Variable is DEPRECATED !
#environnement=

### vitam-itest repository ###
vitam_tests_branch=master
vitam_tests_gitrepo_protocol=
vitam_tests_gitrepo_baseurl=
vitam_tests_gitrepo_url=

# Curator configuration
#	Days before deletion for packetbeat index only on log management cluster
days_to_delete_packetbeat_indexes=5
#	Days before deletion for metricbeat index only on log management cluster; 30 for production environment
days_to_delete_metricbeat_indexes=30
# Days before closing metrics elasticsearch indexes
days_to_close_metrics_indexes=7
# Days before deleting metrics elasticsearch indexes
days_to_delete_metrics_indexes=30
days_to_delete_packetbeat_indexes=20
days_to_delete_metricbeat_indexes=20



# Used when VITAM is behind a reverse proxy (provides configuration for reverse proxy && displayed in header page)
vitam_reverse_external_dns=
# For reverse proxy use
reverse_proxy_port=80
# http_proxy env var to use ; has to be declared even if empty
http_proxy_environnement=

Pour chaque type de « host », indiquer le(s) serveur(s) défini(s) pour chaque fonction. Une colocalisation de composants est possible (Cf. le paragraphe idoine du DAT)

Note

Concernant le groupe « hosts-consul-server », il est nécessaire de déclarer un minimum de 3 machines.

Avertissement

Il n’est pas possible de colocaliser les clusters MongoDB « data » et « offer ».

Avertissement

Il n’est pas possible de colocaliser « kibana-data » et « kibana-log ».

4.2.2.2.2. Fichier vitam_security.yml

La configuration des droits d’accès à VITAM est réalisée dans le fichier environments /group_vars/all/vitam_security.yml, comme suit :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
---

# Business vars

### Admin context name and tenants ###
admin_context_name: "admin-context"
admin_context_tenants: "{{vitam_tenant_ids}}"
# Indicate context certificates relative paths under {{inventory_dir}}/certs/client-external/clients
# vitam-admin-int is mandatory for internal use (PRONOM upload)
admin_context_certs: [ "ihm-demo/ihm-demo.crt", "ihm-recette/ihm-recette.crt", "reverse/reverse.crt", "vitam-admin-int/vitam-admin-int.crt" ]
# Indicate here all the personal certificates relative paths under {{inventory_dir}}/certs/client-vitam-users/clients
admin_personal_certs: [ "userOK.crt" ]

# Admin security profile name
admin_security_profile: "admin-security-profile"

admin_basic_auth_user: "adminUser"

4.2.2.2.3. Fichier offers_opts.yml

Enfin, la déclaration des configuration des offres de stockage est réalisée dans le fichier environments /group_vars/all/offers_opts.yml :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
# This list is ordered. It can and has to be completed if more offers are necessary
# Strategy order (1st has to be the prefered one)
vitam_strategy:
  - name: offer-fs-1
    referent: true
#    vitam_site_name: prod-dc2
#  - name: offer-swift-1
# Example :
#  - name: distant
#    referent: true
#    vitam_site_name: distant-dc2

# DON'T forget to add associated passwords in vault-vitam.yml with same tree when using provider openstack-swift*
# ATTENTION !!! Each offer has to have a distinct name, except for clusters binding a same physical storage
# WARNING : for offer names, please only use [a-z][a-z0-9-]* pattern
vitam_offers:
  offer-fs-1:
    # param can be filesystem-hash (recomended) or filesystem (not recomended)
    provider: filesystem-hash
  offer-swift-1:
    # provider : openstack-swift for v1 or openstack-swift-v3 for v3
    provider: openstack-swift-v3
    # swiftKeystoneAuthUrl : URL de connexion à keystone
    swiftKeystoneAuthUrl: https://openstack-hostname:port/auth/1.0
    # swiftDomain : domaine OpenStack dans lequel l'utilisateur est enregistré
    swiftDomain: domaine
    # swiftUser : identifiant de l'utilisateur
    swiftUser: utilisateur
    # swiftPassword: has to be set in vault-vitam.yml (encrypted) with same structure => DO NOT COMMENT OUT
    # swiftProjectName : nom du projet openstack
    swiftProjectName: monTenant
    # swiftUrl: optional variable to force the swift URL
    # swiftUrl: https://swift-hostname:port/swift/v1

  # example_swift_v1:
  #    provider: openstack-swift
  #    swiftKeystoneAuthUrl: https://keystone/auth/1.0
  #    swiftDomain: domain
  #    swiftUser: user
  #    swiftPassword: has to be set in vault-vitam.yml (encrypted) with same structure => DO NOT COMMENT OUT
  # example_swift_v3:
  #    provider: openstack-swift-v3
  #    swiftKeystoneAuthUrl: https://keystone/v3
  #    swiftDomain: domaine
  #    swiftUser: user
  #    swiftPassword: has to be set in vault-vitam.yml (encrypted) with same structure => DO NOT COMMENT OUT
  #    swiftProjectName: monTenant
  #    projectName: monTenant

Se référer aux commentaires dans le fichier pour le renseigner correctement.

Note

Dans le cas d’un déploiement multi-sites, dans la section vitam_strategy, la directive vitam_site_name définit pour l’offre associée le nom du datacenter consul. Par défaut, si non définie, c’est la valeur de la variable vitam_site_name définie dans l’inventaire.

Avertissement

La cohérence entre l’inventaire et la section vitam_strategy est critique pour le bon déploiement et fonctionnement de la solution logicielle VITAM. En particulier, la liste d’offres de vitam_strategy doit correspondre exactement aux noms d’offre déclarés dans l’inventaire (ou les inventaires de chaque datacenter, en cas de fonctionnement multi-site).

Avertissement

Ne pas oublier, en cas de connexion à un keystone en https, de répercuter dans la PKI la clé publique de la CA du keystone.

4.2.2.2.4. Fichier cots_vars.yml

Dans le cas du choix du COTS d’envoi des messages syslog dans logastsh, il est possible de choisir entre syslog-ng et rsyslog dans le fichier environments /group_vars/all/cots_vars.yml :

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
---

consul:
    dns_port: 53

consul_remote_sites:
    # wan contains the wan addresses of the consul server instances of the external vitam sites
    # Exemple, if our local dc is dc1, we will need to set dc2 & dc3 wan conf:
    # - dc2:
    #   wan: ["10.10.10.10","1.1.1.1"]
    # - dc3:
    #   wan: ["10.10.10.11","1.1.1.1"]

elasticsearch:
    log:
        host: "elasticsearch-log.service.{{ consul_domain }}"
        port_http: "9201"
        port_tcp: "9301"
        groupe: "log"
        baseuri: "elasticsearch-log"
        cluster_name: "elasticsearch-log"
        https_enabled: false
        # default index template
        index_templates:
            default:
                shards: 1
                replica: 1
    data:
        host: "elasticsearch-data.service.{{ consul_domain }}"
        # default is 0.1 (10%) and should be quite enough in most cases
        #index_buffer_size_ratio: "0.15"
        port_http: "9200"
        port_tcp: "9300"
        groupe: "data"
        baseuri: "elasticsearch-data"
        cluster_name: "elasticsearch-data"
        https_enabled: false
        # default index template
        index_templates:
            default:
                shards: 10
                replica: 2

mongodb:
    mongos_port: 27017
    mongoc_port: 27018
    mongod_port: 27019
    mongo_authentication: "true"
    host: "mongos.service.{{ consul_domain }}"

logstash:
    host: "logstash.service.{{ consul_domain }}"
    user: logstash
    port: 10514
    rest_port: 20514

# Curator units: days
curator:
    log:
        metrics:
            close: 5
            delete: 30
        logstash:
            close: 5
            delete: 30
        metricbeat:
            close: 5
            delete: 30
        packetbeat:
            close: 5
            delete: 30

kibana:
    header_value: "reporting"
    log:
        baseuri: "kibana_log"
        api_call_timeout: 120
        groupe: "log"
        port: 5601
        default_index_pattern: "logstash-vitam*"
        # default shards & replica
        shards: 5
        replica: 1
        # pour index logstash-*
        metrics:
            shards: 5
            replica: 1
        # pour index metrics-vitam-*
        logs:
            shards: 5
            replica: 1
        # pour index metricbeat-*
        metricbeat:
            shards: 5 # must be a factor of 30
            replica: 1
    data:
        baseuri: "kibana_data"
        # OMA : bugdette : api_call_timeout is used for retries ; should ceate a separate variable rather than this one
        api_call_timeout: 120
        groupe: "data"
        port: 5601
        default_index_pattern: "logbookoperation_*"
        # index template for .kibana
        shards: 1
        replica: 1

syslog:
    # value can be syslog-ng or rsyslog
    name: "rsyslog"

cerebro:
    baseuri: "cerebro"
    port: 9000

siegfried:
    port: 19000

clamav:
    port: 3310
    # frequency freshclam for database update per day (from 0 to 24 - 24 meaning hourly check)
    db_update_periodicity: 1

mongo_express:
    baseuri: "mongo-express"

ldap_authentification:
    ldap_protocol: "ldap"
    ldap_server: "{% if groups['ldap']|length > 0 %}{{ groups['ldap']|first }}{% endif %}"
    ldap_port: "389"
    ldap_base: "dc=programmevitam,dc=fr"
    ldap_login: "cn=Manager,dc=programmevitam,dc=fr"
    uid_field: "uid"
    ldap_userDn_Template: "uid={0},ou=people,dc=programmevitam,dc=fr"
    ldap_group_request: "(&(objectClass=groupOfNames)(member={0}))"
    ldap_admin_group: "cn=admin,ou=groups,dc=programmevitam, dc=fr"
    ldap_user_group: "cn=user,ou=groups,dc=programmevitam, dc=fr"
    ldap_guest_group: "cn=guest,ou=groups,dc=programmevitam, dc=fr"

Il faut alors modifier la valeur de la directive syslog.name ; la valur par défaut est rsyslog.

4.2.2.3. Déclaration des secrets

Avertissement

Cette section décrit des fichiers contenant des données sensibles ; il convient de sécuriser ces fichiers avec un mot de passe « fort ». En cas d’usage d’un fichier de mot de passe (« vault-password-file »), il faut renseigner ce mot de passe comme contenu du fichier et ne pas oublier de sécuriser ou supprimer ce fichier à l’issue de l’installation.

Les secrets utilisés par la solution logicielle (en-dehors des certificats qui sont abordés dans une section ultérieure) sont définis dans des fichiers chiffrés par ansible-vault.

Important

Tous les vault présents dans l’arborescence d’inventaire doivent être tous protégés par le même mot de passe !

La première étape consiste à changer les mots de passe de tous les vault présents dans l’arborescence de déploiement (le mot de passe par défaut est contenu dans le fichier vault_pass.txt) à l’aide de la commande ansible-vault rekey <fichier vault>.

Voici la liste des vaults pour lesquels il est nécessaire de modifier le mot de passe:

  • environments/group_vars/all/vault-vitam.yml
  • environments/group_vars/all/vault-keystores.yml
  • environments/group_vars/all/vault-extra.yml
  • environments/certs/vault-certs.yml

2 vaults sont principalement utilisés dans le déploiement d’une version ; leur contenu est donc à modifier avant tout déploiement :

  • Le fichier environments /group_vars/all/vault-vitam.yml contient les secrets généraux :

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
    ---
# Vitam platform secret key
plateforme_secret: vitamsecret

# The consul key must be 16-bytes, Base64 encoded: https://www.consul.io/docs/agent/encryption.html
# You can generate it with the "consul keygen" command
# Or you can use this script: deployment/pki/scripts/generate_consul_key.sh
consul_encrypt: Biz14ohqN4HtvZmrXp3N4A==

mongodb:
  mongo-data:
    passphrase: mongogo
    admin:
      user: vitamdb-admin
      password: azerty
    localadmin:
      user: vitamdb-localadmin
      password: qwerty
    metadata:
      user: metadata
      password: azerty1
    logbook:
      user: logbook
      password: azerty2
    report:
      user: report
      password: azerty5
    functionalAdmin:
      user: functional-admin
      password: azerty3
    securityInternal:
      user: security-internal
      password: azerty4
  offer-fs-1:
    passphrase: mongogo
    admin:
      user: vitamdb-admin
      password: azerty
    localadmin:
      user: vitamdb-localadmin
      password: qwerty
    offer:
      user: offer
      password: azerty5
  offer-fs-2:
    passphrase: mongogo
    admin:
      user: vitamdb-admin
      password: azerty
    localadmin:
      user: vitamdb-localadmin
      password: qwerty
    offer:
      user: offer
      password: azerty5
  offer-swift-1:
    passphrase: mongogo
    admin:
      user: vitamdb-admin
      password: azerty
    localadmin:
      user: vitamdb-localadmin
      password: qwerty
    offer:
      user: offer
      password: azerty5

vitam_users:
  - vitam_aadmin:
    login: aadmin
    password: aadmin1234
    role: admin
  - vitam_uuser:
    login: uuser
    password: uuser1234
    role: user
  - vitam_gguest:
    login: gguest
    password: gguest1234
    role: guest
  - techadmin:
    login: techadmin
    password: techadmin1234
    role: admin

ldap_authentification:
    ldap_pwd: "admin"

admin_basic_auth_password: adminPassword

vitam_offers:
    offer-swift-1:
        swiftPassword: password

Note

Dans le cadre d’une installation avec au moins une offre « swift », il faut déclarer, dans la section vitam_offers, le nom de chaque offre et le mot de passe de connexion « swift » associé, défini dans le fichier offers_opts.yml. L’exemple ci-dessus présente la déclaration du mot de passe pour l’offre swift « offer-swift-1 ».

  • Le fichier environments /group_vars/all/vault-keystores.yml contient les mots de passe des magasins de certificats utilisés dans VITAM :

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
    keystores:
  server:
    offer: azerty1
    access_external: azerty2
    ingest_external: azerty3
    ihm_recette: azerty16
    ihm_demo: azerty17
  client_external:
    ihm_demo: azerty4
    gatling: azerty4
    ihm_recette: azerty5
    reverse: azerty6
  client_storage:
    storage: azerty7
  timestamping:
    secure_logbook: azerty8
truststores:
  server: azerty9
  client_external: azerty10
  client_storage: azerty11
grantedstores:
  client_external: azerty12
  client_storage: azerty13

Avertissement

il convient de sécuriser votre environnement en définissant des mots de passe « forts ».

4.2.2.3.1. Cas des extra

  • Le fichier environments /group_vars/all/vault-extra.yml contient les mot de passe des magasins de certificats utilisés dans VITAM :

    1
2
3
    # Example for git lfs ; uncomment & use if needed
#vitam_gitlab_itest_login: "account"
#vitam_gitlab_itest_password: "password"

Note

le playbook vitam.yml comprend des étapes avec la mention no_log afin de ne pas afficher en clair des étapes comme les mots de passe des certificats. En cas d’erreur, il est possible de retirer la ligne dans le fichier pour une analyse plus fine d’un éventuel problème sur une de ces étapes.