mirror of
https://github.com/hanzoai/team.git
synced 2026-09-30 01:57:35 +00:00
b5f007d35e
* docs: resolve cross-file anchor mismatches from RST-to-MDX migration
The Sphinx-to-Docusaurus migration converted `:ref:`/`{ref}` links using
naive text-slugification, so anchors that pointed to headings in a
different file (e.g. release-summary tables linking into their
respective changelog pages) were emitted as same-page fragments and
silently resolved to nothing.
Built a label registry from the original Sphinx `.. _label:` / `(label)=`
targets to recover the true source file for each cross-reference, then
rewrote the affected links to point at the correct file + heading
anchor. Fixes 282 broken cross-file anchors, primarily in the mobile/
desktop/server release-summary pages, plus assorted same-page anchor
mismatches caught by re-auditing after the prior admonition/anchor fix.
* docs: manually resolve remaining anchor mismatches after cross-file audit
Hand-verified fixes for anchors that fuzzy-matching alone couldn't
safely resolve (confirmed against actual heading text/context, and in a
few cases against the original RST source, before applying):
- Typos and dropped words carried over from the original Sphinx docs
(e.g. "bot-acocunts", "auto-follow-all-new-channel-threads" ->
"follow-all-new-channel-threads").
- Sphinx auto-generated duplicate-heading IDs (#id1/#id3/#id4) resolved
to their real target headings.
- Numbered-step TOC links in enterprise-roll-out-checklist.mdx that
dropped the leading "N. " used in the actual heading slugs.
- Push-notification docs pointing at the wrong file entirely
(environment-configuration-settings instead of
push-notification-server-configuration-settings).
- SAML "saml-enterprise" label resolved to its true cross-file target
(authentication-configuration-settings#saml-2-0), recovered from the
original RST label definition that the automated registry missed
because it sat after an RST transition marker.
- sso-saml-technical references converted from broken same-page/
malformed-path anchors to correct page links.
* docs: fix SAML 2.0 anchor slug (saml-2-0 -> saml-20)
github-slugger strips periods rather than hyphenating them, so "SAML
2.0" slugifies to saml-20, not saml-2-0 as previously fixed.
* docs: fix broken path links found during docs/main migration cleanup
* docs: convert div.tab blocks to Docusaurus Tabs/TabItem components
* docs: restore missing Kubernetes deployment architecture diagrams
The RST-to-MDX migration never copied over the AWS/Azure/Oracle
architecture diagrams referenced by the deployment-architecture-at-scale
page, leaving broken images in each Tabs/TabItem.
* docs: fix 7 anchor mismatches from the fragment/heading audit
Covers three root causes from the anchor mismatch breakdown:
- Fragment repeated the target page's own title instead of a real
heading, so the link is simplified to point at the bare page.
- Heading exists verbatim but lives on a sibling settings page
(experimental-configuration-settings, push-notification-server-
configuration-settings) rather than environment-configuration-settings.
- A page path was mistakenly pasted into a same-page #fragment instead
of being used as a real cross-page link.
* docs: fix 8 anchor slugs that were close but didn't match the real heading
Repoints links whose fragment was a plausible guess (typo, reworded
heading, or wrong section) at the actual auto-generated slug of the
target heading, confirmed by inspecting each target page directly.
* docs: merge split Tabs blocks so tabs render horizontally
The div.tab conversion script split some sibling tab groups into
separate single-item Tabs blocks whenever a stray blockquote marker
sat between them, causing them to render stacked instead of as one
horizontal tab bar. Merges the MySQL/PostgreSQL and Team/Enterprise
Edition tab groups back into single Tabs blocks.
* docs: remove Azure tab and restore Kubernetes deploy content
The Mattermost Operator, Azure, and Oracle platform tabs on the
Kubernetes deployment guide were split across two separate Tabs
blocks (rendering stacked instead of as one tab bar) and all three
tab bodies were empty because the migration never flattened the
original RST include directives. Removes the unsupported Azure tab
and restores the Mattermost Operator and Oracle content from the
pre-migration RST sources as a single merged Tabs block.
* addresscoderabbitreview
* docs: unify Linux/Kubernetes/Containers deploy pages and fix FIPS/STIG placement
Kubernetes and Containers duplicated full install content across a top-level
page (Tabs) and orphaned sidebar subpages that nothing linked to. Reworked
both to follow the Linux page's pattern: shared content on the landing page,
platform-specific instructions live once in their own subpage.
Also removed configure-fips-at-install-time.mdx, which claimed FIPS is
available for native Linux installs — FIPS/STIG in Mattermost is a container
image property (Chainguard-based build), not available outside Docker/
Kubernetes. Consolidated all FIPS/STIG references onto
containers/fips-stig.mdx and pointed the Mattermost Operator subpage (not
Oracle OKE, which doesn't expose image selection) at it.
* docs: fix review findings — image alt text, Important callout markup, typo
- Replace generic alt="image" on scaling diagrams with descriptive text
identifying cloud provider and user scale.
- Convert raw div.important markup in deploy-containers.mdx to the
repo's <Important> component, matching usage elsewhere in the file.
- Fix "Matermost" typo in manage-your-display-options.mdx.
---------
Co-authored-by: Hanzo Dev <[email protected]>
122 lines
7.4 KiB
Plaintext
122 lines
7.4 KiB
Plaintext
---
|
||
title: "Quick Start Evaluation"
|
||
---
|
||
import Tabs from '@theme/Tabs';
|
||
import TabItem from '@theme/TabItem';
|
||
|
||
This guide provides instructions for quickly trying out Mattermost using either Docker or Azure Marketplace. These options are ideal for testing and evaluation purposes as they allow you to quickly get a Mattermost instance up and running for exploration and testing. However, these quick start options are not recommended for production use. They are configured for demonstration purposes only.
|
||
|
||
## Deployment options
|
||
|
||
<Tabs>
|
||
<TabItem value="azure-marketplace" label="Azure Marketplace">
|
||
|
||
Mattermost is published as an **Azure Marketplace** solution that deploys a single Ubuntu virtual machine with Mattermost, PostgreSQL, network configurations, and the necessary Azure resources. This quick start evaluation option is preferred for customers already using Azure, as it integrates seamlessly within their existing infrastructure.
|
||
|
||
## Prerequisites
|
||
|
||
- An active **Azure subscription** with permission to create resources and accept **Azure Marketplace** billing terms for the offer.
|
||
- Familiarity with the **Azure portal** (resource groups, networking, and virtual machines).
|
||
|
||
## What gets deployed
|
||
|
||
The template provisions a small, self-contained stack in the resource group you select, including:
|
||
|
||
1. **Virtual machine (Linux):** Runs Mattermost, PostgreSQL, and the reverse proxy.
|
||
2. **Public IP address:** Allows access to the Mattermost workspace over the public internet, enabling users to connect to the platform securely.
|
||
3. **Network interface:** Facilitates communication between the Virtual Machine and other Azure resources through a defined network layer.
|
||
4. **Network security group:** Acts as a virtual firewall, controlling inbound and outbound traffic to protect the deployed resources from unauthorized access.
|
||
5. **Managed OS disk:** Provides persistent storage mounted to the Virtual Machine for storing files generated by Mattermost, including uploaded documents and system configurations.
|
||
6. **Virtual network:** An isolated network environment for the deployed resources, enabling private and controlled connectivity between infrastructure components. This can be a newly created or existing environment depending on your selection in the portal.
|
||
|
||
## Step 1: Select a plan and start creation
|
||
|
||
Go to the [Mattermost - Quick Start Evaluation (VM)](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/mattermost.mattermost-all-in-one) Azure Marketplace application to begin. Click **Get it now**, then select the **Mattermost - Quick Start Evaluation (VM)** plan, and click **Create** to open the deployment wizard.
|
||
|
||
## Step 2: Basic Configuration
|
||
|
||
On the **Basics** tab, configure the following:
|
||
|
||
1. **Subscription:** Choose the Azure subscription where the deployment will live.
|
||
2. **Resource group:** Either select an existing resource group or create a new one. Using a **new** resource group keeps evaluation resources easy to find.
|
||
3. **Region:** Select the deployment region for your Virtual Machine (for example, **East US** or **West Europe**).
|
||
4. **Virtual Machine name:** Provide a unique name for your Virtual Machine.
|
||
5. **Username:** Linux administrator account on the VM.
|
||
6. **Email:** Used for Let's Encrypt registration when the instance requests a TLS certificate. Use a mailbox you can access since you may receive operational emails from the certificate authority.
|
||
7. **Support email:** Contact email for end users to reach the instance administrator for troubleshooting.
|
||
8. **Authentication type:** **Password** or **SSH public key** only for Linux sign-in to the VM. Password is often simpler for a quick trial; SSH key is appropriate if your organization requires key-based Linux access.
|
||
|
||
## Step 3: Virtual Machine Settings and Network Configuration
|
||
|
||
On **Virtual Machine Settings** tab, configure the following:
|
||
|
||
1. **Virtual machine size:** For trials, we recommend **Standard_F2s_v2** size but you can choose any other size available in your region.
|
||
2. **Public IP address:** Typically **create new**. You must set a **DNS prefix** (label) that is **globally unique** in Azure; it forms part of your URL. This DNS will allow public access to your workspace. It is important that you do not already have a matching DNS name within your Azure subscription, or your deployment may fail later in the process.
|
||
3. **Virtual network:** **Create new** with the suggested address space, or attach an existing VNet and subnet that meet the constraints. Using a new virtual network avoids collisions with overlapping address spaces in the same subscription.
|
||
|
||
The portal may show a preview of your URL in the form `https://<dns-label>.<region>.cloudapp.azure.com`. That is the address you will use once TLS and Mattermost are ready.
|
||
|
||
## Step 4: Review and create
|
||
|
||
Review settings, accept any **Marketplace** terms if prompted, then select **Create**. Provisioning usually takes a few minutes, and the first-boot configuration may take more time before HTTPS works reliably.
|
||
|
||
**After deployment completes:**
|
||
|
||
- In the Azure portal, open the **resource group** you used.
|
||
|
||
- Open the **Public IP address** resource (often named `<your-vm-name>-ip` unless you changed it).
|
||
|
||
- Under **Essentials**, note the **DNS name**. Your site URL is:
|
||
|
||
`https://<dns-label>.<region>.cloudapp.azure.com`
|
||
|
||
Example: `https://myorg.eastus.cloudapp.azure.com`
|
||
|
||
Use **https**; the deployment is intended to serve Mattermost over TLS.
|
||
|
||
## Step 5: Open Mattermost and create your administrator
|
||
|
||
In a browser, go to your **HTTPS** URL. Mattermost will prompt you to **create the first user**, which becomes the **System Administrator**. That account is different from the **Linux** username and password (or SSH key) you configured in Step 3.
|
||
|
||
Congratulations! You’ve successfully deployed Mattermost for evaluation.
|
||
|
||
</TabItem>
|
||
<TabItem value="docker-preview-container" label="Docker Preview Container">
|
||
|
||
The fastest way to try Mattermost is using the official Docker preview container. This method requires minimal setup and provides a fully functional Mattermost instance.
|
||
|
||
## Docker Preview Prerequisites
|
||
|
||
- Docker installed on your system
|
||
- At least 1GB of available RAM
|
||
- At least 1GB of available disk space
|
||
|
||
## Run Mattermost using Docker
|
||
|
||
1. Pull and run the Mattermost preview container:
|
||
|
||
> ``` bash
|
||
> docker run --name mattermost-preview -d --publish 8065:8065 mattermost/mattermost-preview
|
||
> ```
|
||
|
||
2. Access Mattermost at `http://localhost:8065`
|
||
3. Create your first admin account when prompted.
|
||
|
||
</TabItem>
|
||
</Tabs>
|
||
|
||
|
||
## Next steps
|
||
|
||
After setting up your Mattermost instance using either method:
|
||
|
||
- Create your first team and channels
|
||
- Invite users to join your workspace
|
||
- Explore Mattermost features and integrations
|
||
- Review the [Application architecture](/deployment-guide/reference-architecture/application-architecture) to understand the system better
|
||
- Consider [Server deployment](/deployment-guide/server/server-deployment-planning) for a production deployment
|
||
|
||
For additional help or questions, visit the [Mattermost community forums](https://forum.mattermost.com/) or refer to the [Deployment troubleshooting](/deployment-guide/deployment-troubleshooting) guide.
|
||
|
||
[Book a live demo](https://mattermost.com/request-demo/) or [talk to a Mattermost expert](https://mattermost.com/contact-sales/) to explore tailored solutions for your organization's secure collaboration needs. Or try Mattermost yourself with a [1-hour preview](https://mattermost.com/sign-up/) for instant access to a live sandbox environment.
|