commit | c3571a84c00da4603eec67146a71b53ebb7f5f88 | [log] [tgz] |
---|---|---|
author | Antonio Barone <syntonyze@gmail.com> | Fri Apr 23 12:01:14 2021 +0200 |
committer | Antonio Barone <syntonyze@gmail.com> | Fri Apr 23 13:43:01 2021 +0200 |
tree | 3d467fd4aec0b9a81b4b1e43d2281a2f341b2753 | |
parent | b6f6350d2f5ae9674292de702abffd4e06032b1a [diff] |
Stream error_log to cloudwatch When running with the `--console-log` flag, the gerrit daemon used to send the logs only to stderr, ignoring the 'log.textLogging' configuration, which instructs gerrit to log on the error_log file. Since stable-3.0, this has been fixed[1]. This means that, for some gerrit versions, the error_log is also available to be streamed to cloudwatch logs. Add error_log to the list of files streamed to cloudwatch, so that (when available) it can be easily identified by name and its content easily distinguished from all other outputs sent to stderr. From gerrit 3.3 this feature is widely available, however it is only available from some minor versions prior to that. Spefically: * from 3.0.13 * from 3.1.10 * from 3.2.5 [1]https://gerrit-review.googlesource.com/c/gerrit/+/276819 been error logs to stderr Bug: Issue 14439 Change-Id: I9367ec39c9cd14e6aa6233148f2345b450393ae1
Those are a collection of AWS CloudFormation templates and scripts to deploy Gerrit in AWS.
The aim is to provide some guidelines and example on how to deploy different Gerrit setups in the Cloud using AWS as provider.
The goal of Gerrit AWS Templates is to provide fully-functional Gerrit installations to helps users deploying Gerrit on AWS by providing out-of-the-box templates.
With Gerrit AWS Templates, developers and administrator can create a production-ready installation on the cloud in minutes and in a repeatable way, allowing them to focus on fine tuning of the Gerrit configuration to suit the user needs.
The provided CloudFormation templates automate the entire creation and deployment of the infrastructure and the application.
To manage your AWS services via command line you will need to install AWS CLI and set it up to point to your account.
To build gerrit and related-components' images Docker
To manipulate aws cloudformation outputs jq
This is a list of external services that you might need to setup your stack and some suggestions on how to easily create them.
If you need to setup a SMTP service Amazon Simple Email Service can be used. Details how setup Amazon SES can be found here.
To correctly setup email notifications Gerrit requires ssl protocol on default port 465 to be enabled on SMTP Server. It is possible to setup Gerrit to talk to standard SMTP port 25 but by default all EC2 instances are blocking it. To enable port 25 please follow this link.
If you need a testing LDAP server you can find details on how to easily create one in the LDAP folder.
All recipes stream every log to CloudWatch. This always includes sshd_log
, httpd_log
and gc_log
.
The ‘error_log’ might or might not be available depending on which version of gerrit is being deployed. From gerrit 3.3 it will always be available. Prior to that it will be available from:
When the error_log
is not available, Gerrit will still output the same content to standard error. Refer to the standard error section.
Different recipes deploy different services to ECS (please refer to the documentation of each recipe for details on what services are actually deployed).
Every ECS service will stream anything outputted to stderr to cloudwatch, to a stream name that will take the form of:
{environmentName}/{serviceName}/{taskId}
For example, given the gerrit-primary
service running task bb21cb504ca44150b770ca05e922e332
, on the test
environment, the stderr will be streamed to:
test/gerrit-primary/bb21cb504ca44150b770ca05e922e332
The task name can be found in the Amazon ECS console's Task
section.