github.com/hechain20/hechain@v0.0.0-20220316014945-b544036ba106/docs/source/deployorderer/ordererchecklist.md (about) 1 # Checklist for a production ordering node 2 3 As you prepare to build a production ordering service (or a single ordering node), you need to customize the configuration by editing the [orderer.yaml](https://github.com/hechain20/hechain/blob/{BRANCH}/sampleconfig/orderer.yaml) file, which is copied into the `/config` directory when downloading the Fabric binaries, and available within the Fabric ordering node image at `/etc/hyperledger/fabric/orderer.yaml`. 4 5 While in a production environment you could override the environment variables in the `orderer.yaml` file in your Docker container or your Kubernetes job, these instructions show how to edit `orderer.yaml` instead. It’s important to understand the parameters in the configuration file and their dependencies on other parameter settings in the file. Blindly overriding one setting using an environment variable could affect the functionality of another setting. Therefore, the recommendation is that before starting the ordering node, you make the modifications to the settings in the configuration file to become familiar with the available settings and how they work. Afterwards, you may choose to override these parameters using environment variables. 6 7 This checklist covers key configuration parameters for setting up a production ordering service. Of course, you can always refer to the orderer.yaml file for additional parameters or more information. It also provides guidance on which parameters should be overridden. The list of parameters that you need to understand and that are described in this topic include: 8 9 * [General.ListenAddress](#general-listenaddress) 10 * [General.ListenPort](#general-listenport) 11 * [General.TLS.*](#general-tls) 12 * [General.Keepalive.*](#general-keepalive) 13 * [General.Cluster.*](#general-cluster) 14 * [General.BoostrapMethod](#general-bootstrapmethod) 15 * [General.BoostrapFile](#general-bootstrapfile) 16 * [General.LocalMSPDir](#general-localmspdir) 17 * [General.LocalMSPID](#general-localmspid) 18 * [FileLedger.Location](#fileledger-location) 19 * [Operations.*](#operations) 20 * [Metrics.*](#metrics) 21 * [Admin.*](#admin) 22 * [ChannelParticipation.*](#channelparticipation) 23 * [Consensus.*](#consensus) 24 25 ## General.ListenAddress 26 27 ``` 28 # Listen address: The IP on which to bind to listen. 29 ListenAddress: 127.0.0.1 30 ``` 31 32 * **`ListenAddress`**: (default value should be overridden) This is the location where the orderer will listen, for example, `0.0.0.0`. Note: unlike the peer, the `orderer.yaml` separates the address and the port, hence the [General.ListenPort](#general-listenport) parameter. 33 34 ## General.ListenPort 35 36 ``` 37 # Listen port: The port on which to bind to listen. 38 ListenPort: 7050 39 ``` 40 41 * **`ListenPort`**: (default value should be overridden) This is the port that the orderer listens on. 42 43 ## General.TLS 44 45 ``` 46 # Require server-side TLS 47 Enabled: false 48 # PrivateKey governs the file location of the private key of the TLS certificate. 49 PrivateKey: tls/server.key 50 # Certificate governs the file location of the server TLS certificate. 51 Certificate: tls/server.crt 52 # RootCAs contains a list additional root certificates used for verifying certificates 53 # of other orderer nodes during outbound connections. 54 # It is not required to be set, but can be used to augment the set of TLS CA certificates 55 # available from the MSPs of each channel’s configuration. 56 RootCAs: 57 - tls/ca.crt 58 # Require client certificates / mutual TLS for inbound connections. 59 ClientAuthRequired: false 60 # If mutual TLS is enabled, ClientRootCAs contains a list of additional root certificates 61 # used for verifying certificates of client connections. 62 # It is not required to be set, but can be used to augment the set of TLS CA certificates 63 # available from the MSPs of each channel’s configuration. 64 ClientRootCAs: 65 ``` 66 67 * **`Enabled`**: (default value should be overridden) In a production network, you should be using TLS-secured communications. This value should be `true`. 68 * **`PrivateKey`**: (default value should be overridden). Provide the path to, and filename of, the private key generated by your TLS CA for this node. 69 * **`Certificate`**: (default value should be overridden) Provide the path to, and filename of, the public certificate (also known as the sign certificate) generated by your TLS CA for this node. 70 * **`RootCAs`**: (should be commented out) This parameter is typically unset for normal use. It is a list of the paths to additional root certificates used for verifying certificates of other orderer nodes during outbound connections. It can be used to augment the set of TLS CA certificates available from the MSPs of each channel's configuration. 71 * **`ClientAuthRequired`**: (Mutual TLS only) Setting this value to “true” will enable mutual TLS on your network, and must be done for the entire network, not just one node. 72 * **`ClientRootCAs`**: (Mutual TLS only) Can be left blank if mutual TLS is disabled. If mutual TLS is enabled, this is a list of the paths to additional root certificates used for verifying certificates of client connections. It can be used to augment the set of TLS CA certificates available from the MSPs of each channel’s configuration. 73 74 ## General.KeepAlive 75 76 The `KeepAlive` values might need to be tuned for compatibility with any networking devices or software (like firewalls or proxies) in between components of your network. Ideally, these settings would be manipulated if needed in a test or pre-prod environment and then set accordingly for your production environment. 77 78 ``` 79 # ServerMinInterval is the minimum permitted time between client pings. 80 # If clients send pings more frequently, the server will 81 # disconnect them. 82 ServerMinInterval: 60s 83 # ServerInterval is the time between pings to clients. 84 ServerInterval: 7200s 85 # ServerTimeout is the duration the server waits for a response from 86 # a client before closing the connection. 87 ServerTimeout: 20s 88 ``` 89 90 * **`ServerMinInterval`**: (default value should not be overridden, unless determined necessary through testing) 91 * **`ServerInterval`**: (default value should not be overridden, unless determined necessary through testing) 92 * **`ServerTimeout`**: (default value should not be overridden, unless determined necessary through testing) 93 94 ## General.Cluster 95 96 ``` 97 # SendBufferSize is the maximum number of messages in the egress buffer. 98 # Consensus messages are dropped if the buffer is full, and transaction 99 # messages are waiting for space to be freed. 100 SendBufferSize: 10 101 # ClientCertificate governs the file location of the client TLS certificate 102 # If not set, the server General.TLS.Certificate is re-used. 103 ClientCertificate: 104 # If not set, the server General.TLS.PrivateKey is re-used. 105 ClientPrivateKey: 106 # The below 4 properties should be either set together, or be unset together. 107 # If they are set, then the orderer node uses a separate listener for intra-cluster 108 # communication. If they are unset, then the general orderer listener is used. 109 # This is useful if you want to use a different TLS server certificates on the 110 # client-facing and the intra-cluster listeners. 111 112 # ListenPort defines the port on which the cluster listens to connections. 113 ListenPort: 114 # ListenAddress defines the IP on which to listen to intra-cluster communication. 115 ListenAddress: 116 # ServerCertificate defines the file location of the server TLS certificate used for intra-cluster 117 # communication. 118 ServerCertificate: 119 # ServerPrivateKey defines the file location of the private key of the TLS certificate. 120 ServerPrivateKey: 121 ``` 122 123 If unset, the `ClientCertificate` and `ClientPrivateKey` default to the server `General.TLS.Certificate` and `General.TLS.PrivateKey` when the orderer is not configured to use a separate cluster port. 124 125 * **`ClientCertificate`**: Provide the path to, and filename of, the public certificate (also known as a signed certificate) generated by your TLS CA for this node. 126 * **`ClientPrivateKey`**: Provide the path to, and filename of, the private key generated by your TLS CA for this node. 127 128 In general, these four parameters would only need to be configured if you want to configure a separate listener and TLS certificates for intra-cluster communication (with other Raft orderers), as opposed to using the listener that peer clients and application clients utilize. This is an advanced deployment option. These four parameters should be set together or left unset, and if they are set, note that the `ClientCertificate` and `ClientPrivateKey` must be set as well. 129 130 * **`ListenPort`** 131 * **`ListenAddress`** 132 * **`ServerCertificate`** 133 * **`ServerPrivateKey`** 134 135 ## General.BoostrapMethod 136 137 ``` 138 # Bootstrap method: The method by which to obtain the bootstrap block 139 # system channel is specified. The option can be one of: 140 # "file" - path to a file containing the genesis block or config block of system channel 141 # "none" - allows an orderer to start without a system channel configuration 142 BootstrapMethod: file 143 ``` 144 145 * **`BootstrapMethod`**: If you plan to create this node on a network that is not using a system channel, override this value to `none` and then ensure that [`ChannelParticipation.Enabled`](#channelparticipation) is set to `true`, otherwise you will get an error when you attempt to start the node. If you are creating a node to be joined to a system channel, unless you plan to use a file type other than “file”, this value should be left as is. 146 147 ## General.BoostrapFile 148 149 ``` 150 # Bootstrap file: The file containing the bootstrap block to use when 151 # initializing the orderer system channel and BootstrapMethod is set to 152 # "file". The bootstrap file can be the genesis block, and it can also be 153 # a config block for late bootstrap of some consensus methods like Raft. 154 # Generate a genesis block by updating $FABRIC_CFG_PATH/configtx.yaml and 155 # using configtxgen command with "-outputBlock" option. 156 # Defaults to file "genesisblock" (in $FABRIC_CFG_PATH directory) if not specified. 157 BootstrapFile: 158 ``` 159 160 * **`BoostrapFile`**: (if you are creating this node to be joined to a system channel, the default value should be overridden) Specify the location and name of the system channel genesis block to use when this node is created. If you are creating this node without using a system channel, this value will not be used, and can therefore be left blank. 161 162 ## General.LocalMSPDir 163 164 ``` 165 # LocalMSPDir is where to find the private crypto material needed by the 166 # orderer. It is set relative here as a default for dev environments but 167 # should be changed to the real location in production. 168 LocalMSPDir: msp 169 ``` 170 171 **`LocalMSPDir`**: (default value will often be overridden) This is the path to the ordering node's local MSP, which must be created before it can be deployed. The path can be absolute or relative to `FABRIC_CFG_PATH` (by default, it is `/etc/hyperledger/fabric` in the orderer image). Unless an absolute path is specified to a folder named something other than "msp", the ordering node defaults to looking for a folder called “msp” at the path (in other words, `FABRIC_CFG_PATH/msp`) and when using the orderer image: `/etc/hyperledger/fabric/msp`. If you are using the recommended folder structure described in the [Registering and enrolling identities with a CA](https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/deployguide/use_CA.html) topic, it would be relative to the `FABRIC_CFG_PATH` as follows: 172 `config/organizations/ordererOrganizations/org0.example.com/orderers/orderer0.org0.example.com/msp`. **The best practice is to store this data in persistent storage**. This prevents the MSP from being lost if your orderer containers are destroyed for some reason. 173 174 ## General.LocalMSPID 175 176 ``` 177 # LocalMSPID is the identity to register the local MSP material with the MSP 178 # manager. IMPORTANT: The local MSP ID of an orderer needs to match the MSP 179 # ID of one of the organizations defined in the orderer system channel's 180 # /Channel/Orderer configuration. The sample organization defined in the 181 # sample configuration provided has an MSP ID of "SampleOrg". 182 LocalMSPID: SampleOrg 183 ``` 184 185 * **`LocalMSPID`**: (default value should be overridden) This identifies the organization this ordering node belongs to. The MSP ID must match the orderer organization MSP ID that exists in the configuration of any channel this joined will be joined to. 186 187 ## General.BCCSP.* 188 189 ``` 190 # Default specifies the preferred blockchain crypto service provider 191 # to use. If the preferred provider is not available, the software 192 # based provider ("SW") will be used. 193 # Valid providers are: 194 # - SW: a software based crypto provider 195 # - PKCS11: a CA hardware security module crypto provider. 196 Default: SW 197 198 # SW configures the software based blockchain crypto provider. 199 SW: 200 # TODO: The default Hash and Security level needs refactoring to be 201 # fully configurable. Changing these defaults requires coordination 202 # SHA2 is hardcoded in several places, not only BCCSP 203 Hash: SHA2 204 Security: 256 205 # Location of key store. If this is unset, a location will be 206 # chosen using: 'LocalMSPDir'/keystore 207 FileKeyStore: 208 KeyStore: 209 ``` 210 211 (Optional) This section is used to configure the Blockchain crypto provider. 212 213 * **`BCCSP.Default:`** If you plan to use a Hardware Security Module (HSM), then this must be set to `PKCS11`. 214 215 ``` 216 # Settings for the PKCS#11 crypto provider (i.e. when DEFAULT: PKCS11) 217 PKCS11: 218 # Location of the PKCS11 module library 219 Library: 220 # Token Label 221 Label: 222 # User PIN 223 Pin: 224 Hash: 225 Security: 226 FileKeyStore: 227 KeyStore: 228 ``` 229 230 * **`BCCSP.PKCS11.*:`** Provide this set of parameters according to your HSM configuration. Refer to this [example](../hsm.html) of an HSM configuration for more information. 231 232 ## FileLedger.Location 233 234 ``` 235 # Location: The directory to store the blocks in. 236 Location: /var/hyperledger/production/orderer 237 ``` 238 239 * **`Location`**: (default value should be overridden in the unlikely event where two ordering nodes are running on the same node) Every channel on which the node is a consenter will have its own subdirectory at this location. The user running the orderer needs to own and have write access to this directory. **The best practice is to store this data in persistent storage**. This prevents the ledger from being lost if your orderer containers are destroyed for some reason. 240 241 ## Operations.* 242 243 The operations service is used for monitoring the health of the ordering node and relies on mutual TLS to secure its communication. Therefore, you need to set `operations.tls.clientAuthRequired` to `true`. When this parameter is set to `true`, clients attempting to ascertain the health of the node are required to provide a valid certificate for authentication. If the client does not provide a certificate or the service cannot verify the client’s certificate, the request is rejected. This means that the clients will need to register with the ordering node's TLS CA and provide their TLS signing certificate on the requests. See [The Operations Service](../operations_service.html) to learn more. 244 245 If you plan to use Prometheus [metrics](#metrics) to monitor your ordering node, you must configure the operations service here. 246 247 In the unlikely case where two ordering nodes are running on the same node on your infrastructure, you need to modify the addresses for the second ordering node to use a different port. Otherwise, when you start the second ordering node, it will fail to start, reporting that the addresses are already in use. 248 249 ``` 250 # host and port for the operations server 251 ListenAddress: 127.0.0.1:8443 252 253 # TLS configuration for the operations endpoint 254 TLS: 255 # TLS enabled 256 Enabled: false 257 258 # Certificate is the location of the PEM encoded TLS certificate 259 Certificate: 260 261 # PrivateKey points to the location of the PEM-encoded key 262 PrivateKey: 263 264 # Most operations service endpoints require client authentication when TLS 265 # is enabled. ClientAuthRequired requires client certificate authentication 266 # at the TLS layer to access all resources. 267 ClientAuthRequired: false 268 269 # Paths to PEM encoded ca certificates to trust for client authentication 270 ClientRootCAs: [] 271 ``` 272 273 * **`ListenAddress`**: (required when using the operations service) Specify the address and port of the operations server. 274 * **`Enabled`**: (required when using the operations service) Must be `true` if the operations service is being used. 275 * **`Certificate`**: (required when using the operations service) Can be the same file as the `General.TLS.Certificate`. 276 * **`PrivateKey`**: (required when using the operations service) Can be the same file as the `General.TLS.PrivateKey`. 277 * **`ClientAuthRequired`**: (required when using the operations service) Must be set to `true` to enable mutual TLS between the client and the server. 278 * **`ClientRootCAs`**: (required when using the operations service) Similar to the client root CA cert file in TLS, it contains a list of client root CA certificates that can be used to verify client certificates. If the client enrolled with the orderer organization CA, then this value is the orderer organization root CA cert. 279 280 ## Metrics.* 281 282 By default this is disabled, but if you want to monitor the metrics for the orderer, you need to use `StatsD` or `Prometheus` as your metric provider. `StatsD` uses a "push" model, pushing metrics from the ordering node to a `StatsD` endpoint. Because of this, it does not require configuration of the operations service itself. `Prometheus` metrics, by contrast, are pulled from an ordering node. 283 284 For more information about the available `Prometheus` metrics, check out [Prometheus](../metrics_reference.html#prometheus) 285 286 For more information about the available `StatsD` metrics, check out [StatsD](../metrics_reference.html#statsd). 287 288 Because Prometheus utilizes a "pull" model there is not any configuration required, beyond making the operations service available. Rather, Prometheus will send requests to the operations URL to poll for available metrics. 289 290 ``` 291 # The metrics provider is one of statsd, prometheus, or disabled 292 Provider: disabled 293 294 # The statsd configuration 295 Statsd: 296 # network type: tcp or udp 297 Network: udp 298 299 # the statsd server address 300 Address: 127.0.0.1:8125 301 302 # The interval at which locally cached counters and gauges are pushed 303 # to statsd; timings are pushed immediately 304 WriteInterval: 30s 305 306 # The prefix is prepended to all emitted statsd metrics 307 Prefix: 308 ``` 309 310 * **`Provider`**: Set this value to `statsd` if using `StatsD` or `prometheus` if using `Prometheus`. 311 * **`Statsd.Address`**: (required to use `StatsD` metrics for the ordering node) When `StatsD` is enabled, you will need to configure the `hostname` and `port` of the `StatsD` server so that the ordering node can push metric updates. 312 313 ## Admin.* 314 315 ``` 316 Admin: 317 # host and port for the admin server 318 ListenAddress: 127.0.0.1:9443 319 320 # TLS configuration for the admin endpoint 321 TLS: 322 # TLS enabled 323 Enabled: false 324 325 # Certificate is the location of the PEM encoded TLS certificate 326 Certificate: 327 328 # PrivateKey points to the location of the PEM-encoded key 329 PrivateKey: 330 331 # Most admin service endpoints require client authentication when TLS 332 # is enabled. ClientAuthRequired requires client certificate authentication 333 # at the TLS layer to access all resources. 334 # 335 # NOTE: When TLS is enabled, the admin endpoint requires mutual TLS. The 336 # orderer will panic on startup if this value is set to false. 337 ClientAuthRequired: true 338 339 # Paths to PEM encoded ca certificates to trust for client authentication 340 ClientRootCAs: [] 341 ``` 342 343 * **`ListenAddress`**: The orderer admin server address (host and port) that can be used by the `osnadmin` command to configure channels on the ordering service. This value should be a unique `host:port` combination to avoid conflicts. 344 * **`TLS.Enabled`**: Technically this can be set to `false`, but this is not recommended. In general, you should always set this value to `true`. 345 * **`TLS.Certificate`**: The path to and file name of the orderer signed certificate issued by the TLS CA. 346 * **`TLS.PrivateKey`**: The path to and file name of the orderer private key issued by the TLS CA. 347 * **`TLS.ClientAuthRequired`**: This value must be set to `true`. Note that while mutual TLS is required for all operations on the orderer `Admin` endpoint, the entire network is not required to use mutual TLS. 348 * **`TLS.ClientRootCAs`**: The path to and file name of the admin client TLS CA root certificate. 349 350 ## ChannelParticipation.* 351 352 ``` 353 ChannelParticipation: 354 # Channel participation API is enabled. 355 Enabled: false 356 357 # The maximum size of the request body when joining a channel. 358 MaxRequestBodySize: 1 MB 359 ``` 360 361 * **`Enabled`**: If you are bootstrapping the ordering node with a system channel genesis block, this value can be set to either `true` or `false` (setting the value to `true` allows you to list channels and to migrate away from the system channel in the future). If you are **not** bootstrapping the ordering node with a system channel genesis block, this value must be set to `true` and the [`General.BoostrapMethod`](#general-boostrapmethod) should be set to `none`. 362 * **`MaxRequestBodySize`**: (default value should not be overridden) This value controls the maximum size a configuration block can be and be accepted by this ordering node. Most configuration blocks are smaller than 1 MB, but if for some reason a configuration block is too large to be accept, bring down the node, increase this value, and restart the node. 363 364 ## Consensus.* 365 366 The values of this section vary by consensus plugin. The values below are for the `etcdraft` consensus plugin. If you are using a different consensus plugin, refer to its documentation for allowed keys and recommended values. 367 368 ``` 369 # The allowed key-value pairs here depend on consensus plugin. For etcd/raft, 370 # we use following options: 371 372 # WALDir specifies the location at which Write Ahead Logs for etcd/raft are 373 # stored. Each channel will have its own subdir named after channel ID. 374 WALDir: /var/hyperledger/production/orderer/etcdraft/wal 375 376 # SnapDir specifies the location at which snapshots for etcd/raft are 377 # stored. Each channel will have its own subdir named after channel ID. 378 SnapDir: /var/hyperledger/production/orderer/etcdraft/snapshot 379 ``` 380 381 * **`WALDir`**: (default value should be overridden) This is the path to the write ahead logs on the local filesystem of the ordering node. It can be an absolute path or relative to `FABRIC_CFG_PATH`. It defaults to `/var/hyperledger/production/orderer/etcdraft/wal`. Each channel will have its own subdirectory named after the channel ID. The user running the ordering node needs to own and have write access to this directory. **The best practice is to store this data in persistent storage**. This prevents the write ahead log from being lost if your orderer containers are destroyed for some reason. 382 * **`SnapDir`**: (default value should be overridden) This is the path to the snapshots on the local filesystem of the ordering node. For more information about how snapshots work in a Raft ordering service, check out [Snapshots](../orderer/ordering_service.html#snapshots)/ It can be an absolute path or relative to `FABRIC_CFG_PATH`. It defaults to `/var/hyperledger/production/orderer/etcdraft/wal`. Each channel will have its own subdirectory named after the channel ID. The user running the ordering node needs to own and have write access to this directory. **The best practice is to store this data in persistent storage**. This prevents snapshots from being lost if your orderer containers are destroyed for some reason. 383 384 For more information about ordering node configuration, including how to set parameters that are not available in `orderer.yaml`, check out [Configuring and operating a Raft ordering service](../raft_configuration.html). 385 386 <!--- Licensed under Creative Commons Attribution 4.0 International License 387 https://creativecommons.org/licenses/by/4.0/) -->