2018-05-22 20:29:33 +02:00
|
|
|
# Deployment options
|
|
|
|
|
|
|
|
The default Zulip installation instructions will install a complete
|
|
|
|
Zulip server, with all of the services it needs, on a single machine.
|
|
|
|
|
|
|
|
For production deployment, however, it's common to want to do
|
2021-08-20 21:53:28 +02:00
|
|
|
something more complicated. This page documents the options for doing so.
|
2018-05-22 20:29:33 +02:00
|
|
|
|
2018-10-17 00:19:51 +02:00
|
|
|
## Installing Zulip from Git
|
|
|
|
|
|
|
|
To install a development version of Zulip from Git, just clone the Git
|
|
|
|
repository from GitHub:
|
|
|
|
|
2021-08-20 07:09:04 +02:00
|
|
|
```bash
|
2018-10-17 00:19:51 +02:00
|
|
|
# First, install Git if you don't have it installed already
|
|
|
|
sudo apt install git
|
|
|
|
git clone https://github.com/zulip/zulip.git zulip-server-git
|
|
|
|
```
|
|
|
|
|
|
|
|
and then
|
2022-02-16 01:39:15 +01:00
|
|
|
[continue the normal installation instructions](install.md#step-2-install-zulip).
|
2023-01-17 04:33:42 +01:00
|
|
|
You can also [upgrade Zulip from Git](upgrade.md#upgrading-from-a-git-repository).
|
2018-10-17 00:19:51 +02:00
|
|
|
|
2021-09-01 00:15:31 +02:00
|
|
|
The most common use case for this is upgrading to `main` to get a
|
2020-07-08 21:14:51 +02:00
|
|
|
feature that hasn't made it into an official release yet (often
|
2021-08-20 21:53:28 +02:00
|
|
|
support for a new base OS release). See [upgrading to
|
2021-09-01 00:15:31 +02:00
|
|
|
main][upgrade-to-main] for notes on how `main` works and the
|
2020-07-08 21:14:51 +02:00
|
|
|
support story for it, and [upgrading to future
|
|
|
|
releases][upgrade-to-future-release] for notes on upgrading Zulip
|
|
|
|
afterwards.
|
|
|
|
|
|
|
|
In particular, we are always very glad to investigate problems with
|
2021-09-01 00:15:31 +02:00
|
|
|
installing Zulip from `main`; they are rare and help us ensure that
|
2020-07-08 21:14:51 +02:00
|
|
|
our next major release has a reliable install experience.
|
|
|
|
|
2023-01-17 03:02:58 +01:00
|
|
|
[upgrade-to-main]: modify.md#upgrading-to-main
|
|
|
|
[upgrade-to-future-release]: modify.md#upgrading-to-future-releases
|
2020-07-08 21:14:51 +02:00
|
|
|
|
2018-10-17 00:27:03 +02:00
|
|
|
## Zulip in Docker
|
|
|
|
|
|
|
|
Zulip has an officially supported, experimental
|
2021-08-20 21:53:28 +02:00
|
|
|
[docker image](https://github.com/zulip/docker-zulip). Please note
|
2022-02-24 00:17:21 +01:00
|
|
|
that Zulip's [normal installer](install.md) has been
|
2018-10-17 00:27:03 +02:00
|
|
|
extremely reliable for years, whereas the Docker image is new and has
|
|
|
|
rough edges, so we recommend the normal installer unless you have a
|
|
|
|
specific reason to prefer Docker.
|
|
|
|
|
2024-02-15 21:18:52 +01:00
|
|
|
## Zulip installer details
|
|
|
|
|
|
|
|
The [Zulip installer](install.md) does the following:
|
|
|
|
|
|
|
|
- Creates the `zulip` user, which the various Zulip servers will run as.
|
|
|
|
- Creates `/home/zulip/deployments/`, which the Zulip code for this
|
|
|
|
deployment (and future deployments when you upgrade) goes into. At the
|
|
|
|
very end of the install process, the script moves the Zulip code tree
|
|
|
|
it's running from (which you unpacked from a tarball above) to a
|
|
|
|
directory there, and makes `/home/zulip/deployments/current` as a
|
|
|
|
symbolic link to it.
|
|
|
|
- Installs Zulip's various dependencies.
|
|
|
|
- Configures the various third-party services Zulip uses, including
|
|
|
|
PostgreSQL, RabbitMQ, Memcached and Redis.
|
|
|
|
- Initializes Zulip's database.
|
|
|
|
|
|
|
|
### Advanced installer options
|
2021-04-18 04:01:20 +02:00
|
|
|
|
|
|
|
The Zulip installer supports the following advanced installer options
|
|
|
|
as well as those mentioned in the
|
2022-02-16 01:39:15 +01:00
|
|
|
[install](install.md#installer-options) documentation:
|
2021-04-18 04:01:20 +02:00
|
|
|
|
2021-08-20 21:45:39 +02:00
|
|
|
- `--postgresql-version`: Sets the version of PostgreSQL that will be
|
2024-11-01 20:51:40 +01:00
|
|
|
installed. We currently support PostgreSQL 13, 14, 15, and 16, with 16
|
2023-12-21 21:46:51 +01:00
|
|
|
being the default.
|
2021-04-18 04:01:20 +02:00
|
|
|
|
2021-08-20 21:45:39 +02:00
|
|
|
- `--postgresql-database-name=exampledbname`: With this option, you
|
2021-03-28 05:41:50 +02:00
|
|
|
can customize the default database name. If you do not set this. The
|
|
|
|
default database name will be `zulip`. This setting can only be set
|
|
|
|
on the first install.
|
|
|
|
|
2021-08-20 21:45:39 +02:00
|
|
|
- `--postgresql-database-user=exampledbuser`: With this option, you
|
2021-03-28 05:41:50 +02:00
|
|
|
can customize the default database user. If you do not set this. The
|
|
|
|
default database user will be `zulip`. This setting can only be set
|
|
|
|
on the first install.
|
|
|
|
|
2024-04-04 23:27:01 +02:00
|
|
|
- `--postgresql-missing-dictionaries`: Set `postgresql.missing_dictionaries`
|
|
|
|
([docs][missing-dicts]) in the Zulip settings, which omits some configuration
|
|
|
|
needed for full-text indexing. This should be used with [cloud managed
|
|
|
|
databases like RDS][postgresql]. This option conflicts with
|
|
|
|
`--no-overwrite-settings`.
|
2021-04-18 04:01:20 +02:00
|
|
|
|
2021-08-20 21:45:39 +02:00
|
|
|
- `--no-init-db`: This option instructs the installer to not do any
|
2021-04-18 04:01:20 +02:00
|
|
|
database initialization. This should be used when you already have a
|
|
|
|
Zulip database.
|
|
|
|
|
2021-08-20 21:45:39 +02:00
|
|
|
- `--no-overwrite-settings`: This option preserves existing
|
2021-04-18 04:01:20 +02:00
|
|
|
`/etc/zulip` configuration files.
|
|
|
|
|
2024-02-16 23:07:19 +01:00
|
|
|
[missing-dicts]: system-configuration.md#missing_dictionaries
|
2023-05-31 00:28:07 +02:00
|
|
|
|
2021-06-03 01:42:15 +02:00
|
|
|
## Installing on an existing server
|
|
|
|
|
|
|
|
Zulip's installation process assumes it is the only application
|
|
|
|
running on the server; though installing alongside other applications
|
|
|
|
is not recommended, we do have [some notes on the
|
2022-02-24 00:17:21 +01:00
|
|
|
process](install-existing-server.md).
|
2021-06-03 01:42:15 +02:00
|
|
|
|
2023-01-30 21:30:34 +01:00
|
|
|
## Deployment hooks
|
|
|
|
|
|
|
|
Zulip's upgrades have a hook system which allows for arbitrary
|
|
|
|
user-configured actions to run before and after an upgrade; see the
|
2023-01-28 02:00:15 +01:00
|
|
|
[upgrading documentation](upgrade.md#deployment-hooks) for details on
|
|
|
|
how to write your own.
|
|
|
|
|
2023-05-30 20:04:29 +02:00
|
|
|
### Zulip message deploy hook
|
|
|
|
|
|
|
|
Zulip can use its deploy hooks to send a message immediately before and after
|
|
|
|
conducting an upgrade. To configure this:
|
|
|
|
|
|
|
|
1. Add `, zulip::hooks::zulip_notify` to the `puppet_classes` line in
|
|
|
|
`/etc/zulip/zulip.conf`
|
|
|
|
1. Add a `[zulip_notify]` section to `/etc/zulip/zulip.conf`:
|
|
|
|
```ini
|
|
|
|
[zulip_notify]
|
|
|
|
bot_email = your-bot@zulip.example.com
|
|
|
|
server = zulip.example.com
|
|
|
|
stream = deployments
|
|
|
|
```
|
2023-05-31 00:28:07 +02:00
|
|
|
1. Add the [api key](https://zulip.com/api/api-keys#get-a-bots-api-key) for the
|
2023-05-30 20:04:29 +02:00
|
|
|
bot user in `/etc/zulip/zulip-secrets.conf` as `zulip_release_api_key`:
|
|
|
|
```ini
|
|
|
|
# Replace with your own bot's token, found in the Zulip UI
|
|
|
|
zulip_release_api_key = abcd1234E6DK0F7pNSqaMSuzd8C5i7Eu
|
|
|
|
```
|
|
|
|
1. As root, run `/home/zulip/deployments/current/scripts/zulip-puppet-apply`.
|
2023-01-28 02:00:15 +01:00
|
|
|
|
|
|
|
### Sentry deploy hook
|
|
|
|
|
|
|
|
Zulip can use its deploy hooks to create [Sentry
|
|
|
|
releases][sentry-release], which can help associate Sentry [error
|
|
|
|
logging][sentry-error] with specific releases. If you are deploying
|
|
|
|
Zulip from Git, it can be aware of which Zulip commits are associated
|
|
|
|
with the release, and help identify which commits might be relevant to
|
|
|
|
an error.
|
|
|
|
|
|
|
|
To do so:
|
|
|
|
|
|
|
|
1. Enable [Sentry error logging][sentry-error].
|
|
|
|
2. Add a new [internal Sentry integration][sentry-internal] named
|
|
|
|
"Release annotator".
|
|
|
|
3. Grant the internal integration the [permissions][sentry-perms] of
|
|
|
|
"Admin" on "Release".
|
|
|
|
4. Add `, zulip::hooks::sentry` to the `puppet_classes` line in `/etc/zulip/zulip.conf`
|
|
|
|
5. Add a `[sentry]` section to `/etc/zulip/zulip.conf`:
|
|
|
|
```ini
|
|
|
|
[sentry]
|
|
|
|
organization = your-organization-name
|
|
|
|
project = your-project-name
|
|
|
|
```
|
2023-05-30 19:55:02 +02:00
|
|
|
6. Add the [authentication token][sentry-tokens] for your internal Sentry integration
|
2023-01-28 02:00:15 +01:00
|
|
|
to your `/etc/zulip/zulip-secrets.conf`:
|
|
|
|
```ini
|
|
|
|
# Replace with your own token, found in Sentry
|
|
|
|
sentry_release_auth_token = 6c12f890c1c864666e64ee9c959c4552b3de473a076815e7669f53793fa16afc
|
|
|
|
```
|
|
|
|
7. As root, run `/home/zulip/deployments/current/scripts/zulip-puppet-apply`.
|
|
|
|
|
|
|
|
If you are deploying Zulip from Git, you will also need to:
|
|
|
|
|
|
|
|
1. In your Zulip project, add the [GitHub integration][sentry-github].
|
|
|
|
2. Configure the `zulip/zulip` GitHub project for your Sentry project.
|
|
|
|
You should do this even if you are deploying a private fork of
|
|
|
|
Zulip.
|
|
|
|
3. Additionally grant the internal integration "Read & Write" on
|
|
|
|
"Organization"; this is necessary to associate the commits with the
|
|
|
|
release.
|
|
|
|
|
|
|
|
[sentry-release]: https://docs.sentry.io/product/releases/
|
|
|
|
[sentry-error]: ../subsystems/logging.md#sentry-error-logging
|
|
|
|
[sentry-github]: https://docs.sentry.io/product/integrations/source-code-mgmt/github/
|
|
|
|
[sentry-internal]: https://docs.sentry.io/product/integrations/integration-platform/internal-integration/
|
|
|
|
[sentry-perms]: https://docs.sentry.io/product/integrations/integration-platform/#permissions
|
|
|
|
[sentry-tokens]: https://docs.sentry.io/product/integrations/integration-platform/internal-integration#auth-tokens
|
2023-01-30 21:30:34 +01:00
|
|
|
|
2018-05-22 20:29:33 +02:00
|
|
|
## Running Zulip's service dependencies on different machines
|
|
|
|
|
2024-04-04 20:54:35 +02:00
|
|
|
Zulip has full support for each top-level service living on its own machine.
|
2018-05-22 20:29:33 +02:00
|
|
|
|
2024-04-04 20:54:35 +02:00
|
|
|
You can configure remote servers for Memcached, PostgreSQL, RabbitMQ, Redis, and
|
|
|
|
Smokescreen in `/etc/zulip/settings.py`; just search for the service name in
|
|
|
|
that file and you'll find inline documentation in comments for how to configure
|
|
|
|
it.
|
2018-05-22 20:29:33 +02:00
|
|
|
|
2020-10-20 02:49:54 +02:00
|
|
|
All puppet modules under `zulip::profile` are allowed to be configured
|
2021-08-20 21:53:28 +02:00
|
|
|
stand-alone on a host. You can see most likely manifests you might
|
2020-10-20 02:49:54 +02:00
|
|
|
want to choose in the list of includes in [the main manifest for the
|
2020-10-20 03:49:23 +02:00
|
|
|
default all-in-one Zulip server][standalone.pp], though it's also
|
2020-10-20 02:49:54 +02:00
|
|
|
possible to subclass some of the lower-level manifests defined in that
|
2021-08-20 21:53:28 +02:00
|
|
|
directory if you want to customize. A good example of doing this is
|
2024-02-06 21:40:19 +01:00
|
|
|
in the [kandra Puppet configuration][zulipchat-puppet] that we use
|
2020-10-20 02:49:54 +02:00
|
|
|
as part of managing chat.zulip.org and zulip.com.
|
2018-05-22 20:29:33 +02:00
|
|
|
|
2024-04-04 23:27:01 +02:00
|
|
|
For example, to install a Zulip Redis server on a machine, you can run
|
|
|
|
the following after unpacking a Zulip production release tarball:
|
2019-12-12 10:50:04 +01:00
|
|
|
|
2021-08-20 07:09:04 +02:00
|
|
|
```bash
|
2024-04-04 23:27:01 +02:00
|
|
|
./scripts/setup/install --puppet-classes zulip::profile::redis
|
2019-12-12 10:50:04 +01:00
|
|
|
```
|
|
|
|
|
2024-04-04 23:27:01 +02:00
|
|
|
To run the database on a separate server, including a cloud provider's managed
|
2024-07-04 12:33:43 +02:00
|
|
|
PostgreSQL instance (e.g., AWS RDS), or with a warm-standby replica for
|
2024-05-08 01:57:20 +02:00
|
|
|
reliability, see our [dedicated PostgreSQL documentation][postgresql].
|
2019-12-12 10:50:04 +01:00
|
|
|
|
2024-04-04 23:27:01 +02:00
|
|
|
[standalone.pp]: https://github.com/zulip/zulip/blob/main/puppet/zulip/manifests/profile/standalone.pp
|
|
|
|
[zulipchat-puppet]: https://github.com/zulip/zulip/tree/main/puppet/kandra/manifests
|
|
|
|
[postgresql]: postgresql.md
|
2018-05-22 20:29:33 +02:00
|
|
|
|
2019-06-17 21:16:34 +02:00
|
|
|
## Using an alternate port
|
|
|
|
|
|
|
|
If you'd like your Zulip server to use an HTTPS port other than 443, you can
|
|
|
|
configure that as follows:
|
|
|
|
|
|
|
|
1. Edit `EXTERNAL_HOST` in `/etc/zulip/settings.py`, which controls how
|
|
|
|
the Zulip server reports its own URL, and restart the Zulip server
|
|
|
|
with `/home/zulip/deployments/current/scripts/restart-server`.
|
|
|
|
1. Add the following block to `/etc/zulip/zulip.conf`:
|
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```ini
|
|
|
|
[application_server]
|
|
|
|
nginx_listen_port = 12345
|
|
|
|
```
|
2019-06-17 21:16:34 +02:00
|
|
|
|
|
|
|
1. As root, run
|
2021-08-20 22:54:08 +02:00
|
|
|
`/home/zulip/deployments/current/scripts/zulip-puppet-apply`. This
|
|
|
|
will convert Zulip's main `nginx` configuration file to use your new
|
|
|
|
port.
|
2019-06-17 21:16:34 +02:00
|
|
|
|
|
|
|
We also have documentation for a Zulip server [using HTTP][using-http] for use
|
|
|
|
behind reverse proxies.
|
|
|
|
|
2024-02-16 23:07:19 +01:00
|
|
|
[using-http]: reverse-proxies.md#configuring-zulip-to-allow-http
|
2019-06-17 21:16:34 +02:00
|
|
|
|
2021-11-17 22:17:56 +01:00
|
|
|
## Customizing the outgoing HTTP proxy
|
2020-10-15 11:43:44 +02:00
|
|
|
|
2021-11-17 22:17:56 +01:00
|
|
|
To protect against [SSRF][ssrf], Zulip 4.8 and above default to
|
|
|
|
routing all outgoing HTTP and HTTPS traffic through
|
|
|
|
[Smokescreen][smokescreen], an HTTP `CONNECT` proxy; this includes
|
|
|
|
outgoing webhooks, website previews, and mobile push notifications.
|
2022-01-08 00:19:31 +01:00
|
|
|
By default, the Camo image proxy will be automatically configured to
|
|
|
|
use a custom outgoing proxy, but does not use Smokescreen by default
|
|
|
|
because Camo includes similar logic to deny access to private
|
|
|
|
subnets. You can [override][proxy.enable_for_camo] this default
|
|
|
|
configuration if desired.
|
2020-10-15 11:43:44 +02:00
|
|
|
|
2021-11-17 22:17:56 +01:00
|
|
|
To use a custom outgoing proxy:
|
2021-05-13 20:03:57 +02:00
|
|
|
|
2020-10-15 11:43:44 +02:00
|
|
|
1. Add the following block to `/etc/zulip/zulip.conf`, substituting in
|
|
|
|
your proxy's hostname/IP and port:
|
|
|
|
|
2021-08-20 22:54:08 +02:00
|
|
|
```ini
|
|
|
|
[http_proxy]
|
|
|
|
host = 127.0.0.1
|
|
|
|
port = 4750
|
|
|
|
```
|
2020-10-15 11:43:44 +02:00
|
|
|
|
|
|
|
1. As root, run
|
2021-08-20 21:53:28 +02:00
|
|
|
`/home/zulip/deployments/current/scripts/zulip-puppet-apply`. This
|
2021-11-17 22:17:56 +01:00
|
|
|
will reconfigure and restart Zulip.
|
|
|
|
|
|
|
|
If you have a deployment with multiple frontend servers, or wish to
|
|
|
|
install Smokescreen on a separate host, you can apply the
|
|
|
|
`zulip::profile::smokescreen` Puppet class on that host, and follow
|
|
|
|
the above steps, setting the `[http_proxy]` block to point to that
|
|
|
|
host.
|
|
|
|
|
|
|
|
If you wish to disable the outgoing proxy entirely, follow the above
|
|
|
|
steps, configuring an empty `host` value.
|
|
|
|
|
|
|
|
Optionally, you can also configure the [Smokescreen ACL
|
|
|
|
list][smokescreen-acls]. By default, Smokescreen denies access to all
|
|
|
|
[non-public IP
|
|
|
|
addresses](https://en.wikipedia.org/wiki/Private_network), including
|
|
|
|
127.0.0.1, but allows traffic to all public Internet hosts.
|
2021-02-26 23:40:18 +01:00
|
|
|
|
2021-11-17 22:17:56 +01:00
|
|
|
In Zulip 4.7 and older, to enable SSRF protection via Smokescreen, you
|
|
|
|
will need to explicitly add the `zulip::profile::smokescreen` Puppet
|
|
|
|
class, and configure the `[http_proxy]` block as above.
|
2020-10-15 11:43:44 +02:00
|
|
|
|
2024-02-16 23:07:19 +01:00
|
|
|
[proxy.enable_for_camo]: system-configuration.md#enable_for_camo
|
2020-10-15 11:43:44 +02:00
|
|
|
[smokescreen]: https://github.com/stripe/smokescreen
|
2021-05-13 20:03:57 +02:00
|
|
|
[smokescreen-acls]: https://github.com/stripe/smokescreen#acls
|
2021-02-26 23:40:18 +01:00
|
|
|
[ssrf]: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery
|
2020-10-15 11:43:44 +02:00
|
|
|
|
2022-03-23 21:47:53 +01:00
|
|
|
### S3 file storage requests and outgoing proxies
|
|
|
|
|
|
|
|
By default, the [S3 file storage backend][s3] bypasses the Smokescreen
|
|
|
|
proxy, because when running on EC2 it may require metadata from the
|
|
|
|
IMDS metadata endpoint, which resides on the internal IP address
|
|
|
|
169.254.169.254 and would thus be blocked by Smokescreen.
|
|
|
|
|
|
|
|
If your S3-compatible storage backend requires use of Smokescreen or
|
|
|
|
some other proxy, you can override this default by setting
|
|
|
|
`S3_SKIP_PROXY = False` in `/etc/zulip/settings.py`.
|
|
|
|
|
|
|
|
[s3]: upload-backends.md#s3-backend-configuration
|