本文档旨在为开始部署CAS Server 提供一个指导思路，为CAS 部署人员提供一个合适的流程以帮助他们成功的架构和部署CAS Server。
1、收集用例
在部署之前对所需的用例和需求进行文档记录、编目和分析是非常重要的。一旦您有了一些想法，请与CAS社区讨论并共享这些想法，以了解可能已经解决了您今天面临的相同问题的共同趋势、实践和模式。
2、学习架构
理解CAS 是什么以及它能够做什么是很重要的，这可以帮助您使用CAS来完成用例和需求的基础搭建，您可以通过《CAS SSO介绍》了解CAS的架构。
同样的学习CAS 所支持的协议和规范也很重要，CAS所支持的协议和规范将在后续的文章中逐步介绍。
3、阅读博客
通常，Apereo Blog 所展现的文章能够帮助您考虑您的需求和分析特性。通常建议您关注这个博客，尽可能多地了解项目新闻和公告，不要回避在整个CAS部署过程中撰写和贡献您自己的博客文章、经验和更新。
4、准备环境
CAS 6.1.X版本的安装环境要求如下：
（1）JDK：JDK 11 及以上
（2）Servlet 容器：没有指定特定的Servlet容器，但是Apache Tomcat是最常用的选择。
（3）构建工具：不需要单独安装Gradle，Cas已实现自动化构建。
（4）Git(可选)：虽然不是严格的要求，但强烈建议您为CAS部署安装Git，并在源代码控制存储库中管理所有CAS构件、配置文件、构建脚本和设置。
（5）操作系统：虽然不指定，但是Linux相比Windows更加通用。
（6）网络：任何基于Maven/Gradle的项目的构建阶段通常都需要Internet连接，包括用于安装CAS的推荐WAR覆盖。构建过程通过搜索包含在本地下载和安装的组件(大多数情况下是jar文件)的在线存储库来解决依赖关系。
（7）硬件：坊间证据似乎表明，CAS部署在双核(3.00Ghz)处理器和8GB内存(至少)的情况下性能良好。如果日志保存在服务器本身，那么还需要足够的磁盘空间(最好是SSD)来存放由cas生成的日志。
5、部署CAS
建议使用 WAR 包覆盖的方式安装（详细的安装步骤后续文章再进行介绍），这种方法不需要采用者显式地下载任何版本的CAS，而是利用覆盖机制来组合CAS原始构件和本地定制，从而进一步简化未来的升级和维护。
CAS安装是一个基本的面向源代码的过程，我们建议使用WAR overlay项目来组织定制，比如组件配置和UI设计。WAR覆盖构建的输出是cas.war文件，该文件可以直接部署到servlet容器(如Apache Tomcat)。
覆盖是一种避免重复代码/或资源的策略。与下载CAS代码库并从源代码构建不同，overlay允许您下载项目本身提供的预构建的通用CAS web应用服务器，并覆盖/插入特定的行为。在构建时，构建安装过程将首先尝试下载提供的二进制工件，然后该工具将定位您的配置文件和在相同的项目目录中可用的设置，并将它们合并到下载的工件中，以生成一个完整的归档文件(例如：case .war)。被覆盖的工件可能包括资源、java类、图像、CSS和javascript文件。为了成功地执行合并过程，本地被覆盖工件的位置和名称必须与最初下载的归档文件中项目提供的位置和名称完全匹配。您可以覆盖项目的 src/main/java文件夹中的Java代码和src/main/resources中的资源，甚至是cas.war中的的WEB-INF\classes文件夹。它们将由类加载器加载，而不是由WEB-INF\lib中的jar文件中具有相同名称的资源加载。
不用说，虽然预先启动时间可能有点复杂，但这种方法有以下明显的优势:
- 不需要从源代码下载/构建；
- 在大多数情况下，只需调整构建脚本以下载更新的CAS版本，升级就会变得非常容易；
- 与托管整个软件源代码不同，作为部署人员，您只保留自己的本地自定义，这使得更改跟踪更加容易；
- 因为您只管理相关的更改(而不是整个软件)，这样使得您跟踪源代码控制存储库中的更改变得非常轻量级。
管理覆盖：
可以通过在覆盖层中添加、删除或修改文件来控制CAS的大部分切面(如果不是全部的话);通过添加实现了CAS api的Java源文件或依赖项引用的第三方组件来定制CAS的行为也是可能的，也是最常见的做法。
使用overlay的过程可以总结为以下几个步骤:
A.开始并构建所提供的基本构建/部署，模板可参见 CAS WAR Overlay项目。
B.从生成的构建中确定需要更改的构件。这些工件通常由Gradle的build目录中的build命令生成，可以使用gradle的explodeWar 任务。
C.将标识的工件从上面标识的目录复制到src/main/resources目录:
创建src/main/resources 目录，如果这个目录不存在的话；
复制的路径和文件名必须与对应的构建版本完全匹配，否则更改将不起作用。请参阅下面的表，以了解如何将文件夹和文件从构建映射到src。
D.更改之后，重新构建并尽可能多地复用该过程；
E.在构建的二进制工件中仔细检查您的更改，以确保覆盖过程正常工作。
注意：不要复制生成的所有内容。尽量减少更改和自定义，只获取实际需要的内容。确保部署环境保持整洁和精确，否则您将面临严重的升级问题和极大的风险。
在做任何其他事情之前，先建立一个功能基线是非常重要的。避免立即进行特别更改以自定义部署。坚持使用cas提供的默认设置和设置，每次只做一步更改。当您取得进展时，请跟踪过程和源代码控制中的应用更改以及标记更改。
6、自定义建议
自定义修改时需要研究清楚需求用例与CAS 特性的映射关系，这需要您浏览文档来寻找最匹配的特性进行应用。但是以下红线希望您不要踩踏：
- 避免对软件内部进行特别的更改；
- 避免对核心配置组件(如Spring和Spring Webflow)进行手动更改；
- 如果遇到问题，避免对部署进行一次性的错误修复。
相反，以下建议希望您遵从：
- 任何属于CAS core 的Bug修复和小的改进（不包含您自己开发的部分），希望您能尽一切努力向CAS报告，提供修复方案和补丁，并与CAS社区合作一次性解决这些问题；
- 一定数量的内部CAS组件难以扩充和修改。在大多数情况下，这种方法的目的是引导您远离危险和不必要的复杂更改。如果您遇到一个需要和有一个特性或用例的配置和实现需要修改的核心内部软件,希望您能参与社区讨论,并尝试增强直接构建到CAS软件,而不是把它作为一个雪花。
总而言之，只有在部署配置真正且完全特定于您的需求时才进行更改。否则，试着总结和贡献，以保持维护成本低。反复地，不遵守这一战略从长远来看可能会导致灾难性的后果。
7、故障排查
故障排查指南可能会对您可能遇到的问题提供一些答案，它通常尝试描述一种对故障排除和诊断有用的策略。你也可以向CAS维护团队寻求协助。
