diff --git a/_data/devops-checklist.yml b/_data/devops-checklist.yml index 660ea74f3..8ca360665 100644 --- a/_data/devops-checklist.yml +++ b/_data/devops-checklist.yml @@ -28,7 +28,7 @@ You have several options for running Docker containers in AWS. One is to use the Elastic Container Service (ECS), where you run a cluster of EC2 Instances, and Amazon takes care of scheduling containers across them. Another is - Elasic Kubernetes Service (EKS), which is a Amazon's + Elastic Kubernetes Service (EKS), which is a Amazon's managed Kubernetes (note, EKS is still in preview mode as of May, 2018). A third option is AWS Fargate, a service where AWS manages and scales the underlying EC2 Instances for you and you just hand it Docker @@ -112,7 +112,7 @@ description: | Use CloudFront as a Content Distribution Network (CDN) - to cache and distribute your content across servers all over the world. This signicantly reduces latency for + to cache and distribute your content across servers all over the world. This significantly reduces latency for users and is especially effective for static content. - title: Configure caching @@ -540,7 +540,7 @@ - title: Set up SSH access description: | Do NOT share EC2 KeyPairs - with your team! Otherwise, everyone will be using the same username and key for server acesss (so there's no + with your team! Otherwise, everyone will be using the same username and key for server access (so there's no audit trail), the key may easily be compromised, and if it is, or someone leaves the company, you'll have to redeploy ALL your EC2 Instances to change the KeyPair. Instead, configure your EC2 Instances so that each developer can use their own username and SSH key, and if that developer leaves the company, the key can be @@ -560,7 +560,7 @@ - title: Deploy a VPN Server description: | - We typically recommend running a VPN Server as the entrypoint to your network (as the Bastion Host). + We typically recommend running a VPN Server as the entry point to your network (as the Bastion Host). OpenVPN is the most popular option for running a VPN server. - title: Set up a secrets management solution @@ -723,7 +723,7 @@ description: | EC2 Spot Instances allow you to "bid" a much lower price for EC2 Instances than what you'd pay on-demand (as much as 90% lower!), and when there is capacity - to fulfill your request, AWS will give you the EC2 Instances at that price. Note that if AWS needs to relcaim + to fulfill your request, AWS will give you the EC2 Instances at that price. Note that if AWS needs to reclaim that capacity, it may terminate the EC2 Instance at any time with a 2-minute notice. This makes Spot Instances a great way to save money on any workload that is non-urgent (e.g., all background jobs, machine learning, image processing) and pre-production environments (e.g., run an ECS cluster on spot instances by just setting a diff --git a/_data/library.yml b/_data/library.yml index a4562abb4..4b6a00856 100644 --- a/_data/library.yml +++ b/_data/library.yml @@ -413,7 +413,7 @@ description: An AWS Lambda function that can automatically share an RDS snapshot with another AWS account. Useful for storing your RDS backups in a separate backup account. - name: lambda-copy-shared-snapshot blurb: copy RDS snapshots - description: An AWS Lambda function that can make a local copy of an RDS snapshot shared from another AWS account. Useful for storing yoru RDS backups in a separate backup account. + description: An AWS Lambda function that can make a local copy of an RDS snapshot shared from another AWS account. Useful for storing your RDS backups in a separate backup account. - name: lambda-cleanup-snapshots blurb: delete RDS snapshots description: An AWS Lambda function that runs on a scheduled basis to clean up old RDS database snapshots. Useful to ensure you aren't spending lots of money storing old snapshots you no longer need. diff --git a/_data/privacy-policy.yml b/_data/privacy-policy.yml index 6cf6ba3da..5d16a7066 100644 --- a/_data/privacy-policy.yml +++ b/_data/privacy-policy.yml @@ -206,10 +206,10 @@
  • Inferences, including information about your interests and preferences.
  • Internet activity, including your interactions with the Services and what led you to Gruntwork.
    • -

    The Purposes for Our Collection: We collect and use these categories of personal data for our business and commercial purposes described in the “How do we use your information” section above, including providing and improving the Services, maintaining the safety and security of the Services, and for advertising and marketing our business.

    +

    The Purposes for Our Collection: We collect and use these categories of personal data for our business and commercial purposes described in the “How do we use your information” section above, including providing and improving the Services, maintaining the safety and security of the Services, and for advertising and marketing our business.

    Third-Party Marketing and Your Rights (Opt-Out of “Sale”): Gruntwork does not sell personal data to third parties for monetary value. However, the term “sale” is defined broadly in the CCPA. To the extent that “sale” under the CCPA is interpreted to include interest-based advertising or other data uses described in the “How do we use your information” section above, we will comply with applicable law with respect to those uses.

    “Do Not Track” Signals: We do not recognize or respond to any web browser-initiated “Do Not Track” signals. At present, no universally accepted standard exists on how companies should respond to “Do Not Track” signals. In the event a universally accepted standard is established, we will assess and provide an appropriate response to these signals. If you wish, you can configure most browsers to reject cookies or to notify you when you are sent a cookie, giving you a chance to decide whether or not to accept it. Consult the help section of your browser to learn more about how to do this. Please note that if you choose to remove or reject cookies, this could affect the availability and functionality of the Services.

    -

    Shine The Light: California Civil Code §1798.83 permits users of the Website who are California residents to request certain information regarding our disclosure of personal data to third parties for their direct marketing purposes. Gruntwork does not share personal data with third parties for their direct marketing purposes.

    +

    Shine The Light: California Civil Code §1798.83 permits users of the Website who are California residents to request certain information regarding our disclosure of personal data to third parties for their direct marketing purposes. Gruntwork does not share personal data with third parties for their direct marketing purposes.

    - question: Changes to our Privacy Policy items: diff --git a/_data/reference-architecture.yml b/_data/reference-architecture.yml index bb20f9c0b..14a1d820f 100644 --- a/_data/reference-architecture.yml +++ b/_data/reference-architecture.yml @@ -33,7 +33,7 @@ infrastructure: - title: Bastion host description: | - Choose from either a plain bastion host or an OpenVPN server as the sole entrypoint to your network. + Choose from either a plain bastion host or an OpenVPN server as the sole entry point to your network. - title: CI server description: | diff --git a/_data/terms-of-service.yml b/_data/terms-of-service.yml index bc651418c..9efca4bce 100644 --- a/_data/terms-of-service.yml +++ b/_data/terms-of-service.yml @@ -16,7 +16,7 @@ items: - title: 1. Updates to these Terms legalese: | -

    1.1. Revisions. We may revise these Terms or any additional terms and conditions which are relevant to a particular Service from time-to-time. We will post the revised terms to our website (currently https://gruntwork.io/terms) (the “Website”) with a “last updated” date, and we will attempt to notify you of any material updates to these Terms via email or through the Services. IF YOU CONTINUE TO USE THE SERVICES AFTER THE REVISIONS TAKE EFFECT, YOU AGREE TO BE BOUND BY THE REVISED TERMS. You agree that we shall not be liable to you or to any third party for any modification of the Terms.

    +

    1.1. Revisions. We may revise these Terms or any additional terms and conditions which are relevant to a particular Service from time-to-time. We will post the revised terms to our website (currently https://gruntwork.io/terms) (the “Website”) with a “last updated” date, and we will attempt to notify you of any material updates to these Terms via email or through the Services. IF YOU CONTINUE TO USE THE SERVICES AFTER THE REVISIONS TAKE EFFECT, YOU AGREE TO BE BOUND BY THE REVISED TERMS. You agree that we shall not be liable to you or to any third party for any modification of the Terms.

    1.2. Notifying You of Updates. You agree to receive electronically all communications, agreements, and notices that we provide in connection with any Services (“Communications”), including by email, by posting them to our website, or through any Services. You agree that all Communications that we provide to you electronically satisfy any legal requirement that such Communications be in writing and you agree to keep your Account contact information current.

    plain: | We might update these Terms of Service at some point, and if we do, we'll proactively notify you about it. diff --git a/_data/where-we-work.yml b/_data/where-we-work.yml index 6398b3833..9aca14629 100644 --- a/_data/where-we-work.yml +++ b/_data/where-we-work.yml @@ -8,8 +8,6 @@ position: [26%, 6%] - location: London, England position: [18%, 43%] -- location: Lagos, Nigeria - position: [51%, 45%] - location: Orlando, FL position: [35%, 18%] - location: New York, NY @@ -18,9 +16,13 @@ position: [25%, 22%] - location: Woodbury, CT position: [25%, 21%] -- location: Woodbury, CT - position: [25%, 21%] -- location: Helsinki, Finland - position: [13%, 50.5%] - location: Berlin, Germany position: [20%, 48%] +- location: Calgary, Canada + position: [19%, 12%] +- location: Chicago, Illinois + position: [23%, 17%] +- location: San Francisco, CA + position: [25%, 6%] +- location: Portland, OR + position: [21%, 9%] diff --git a/_posts/2019-05-08-deploying-a-dockerized-app-on-gcp-gke.adoc b/_posts/2019-05-08-deploying-a-dockerized-app-on-gcp-gke.adoc index 0e00f5ada..607252455 100644 --- a/_posts/2019-05-08-deploying-a-dockerized-app-on-gcp-gke.adoc +++ b/_posts/2019-05-08-deploying-a-dockerized-app-on-gcp-gke.adoc @@ -90,7 +90,7 @@ using the Gruntwork Infrastructure as Code Library. [[pre_requisites]] === Pre-requisites -This walkthrough has the following pre-requistes: +This walkthrough has the following pre-requisites: Terraform:: This guide uses https://www.terraform.io/[Terraform] to define and manage all the infrastructure as code. If you're diff --git a/_posts/2019-08-12-how-to-configure-production-grade-aws-account-structure.adoc b/_posts/2019-08-12-how-to-configure-production-grade-aws-account-structure.adoc index a0307f5ba..8045caac5 100644 --- a/_posts/2019-08-12-how-to-configure-production-grade-aws-account-structure.adoc +++ b/_posts/2019-08-12-how-to-configure-production-grade-aws-account-structure.adoc @@ -683,7 +683,7 @@ and automated users in your child accounts. The exact set of IAM roles you need requirements, but here are some common ones: allow-auto-deploy-access-from-other-accounts:: - This is an IAM role that grants permissions for automatically deploying (e.g., as part of a CI / CD pipline) + This is an IAM role that grants permissions for automatically deploying (e.g., as part of a CI / CD pipeline) some specific service. For example, this role may have a trust policy that allows it to be assumed by a Jenkins server in the shared-services account, and gives that server permissions to deploy EC2 Instances and Auto Scaling Groups. Note that anyone who has to your CI server (e.g., anyone who can create/modify/execute Jenkins jobs) can @@ -886,7 +886,7 @@ the central place where you manage billing. You create this initial account manu === Apply the security baseline to the root account Next, we'll apply a security baseline to the root account that is responsible for configuring AWS Organizations, IAM Roles, IAM Users, -IAM Groups, IAM Password Policies, Amazon GuardyDuty, AWS CloudTrail and AWS Config including setting up the child accounts. +IAM Groups, IAM Password Policies, Amazon GuardDuty, AWS CloudTrail and AWS Config including setting up the child accounts. Let's first apply the security baseline by using the `account-baseline-root` module from https://github.com/gruntwork-io/module-security[module-security]. @@ -1000,7 +1000,7 @@ variable "child_accounts" { # Defaults to the Organization default Root ID. # # - role_name: - # The name of an IAM role that Organizations automatically preconfigures in the new member account. This role trusts + # The name of an IAM role that Organizations automatically pre-configures in the new member account. This role trusts # the master account, allowing users in the master account to assume the role, as permitted by the master account # administrator. The role has administrator permissions in the new member account. Note that the Organizations API # provides no method for reading this information after account creation. diff --git a/_posts/2019-08-13-how-to-deploy-production-grade-vpc-aws.adoc b/_posts/2019-08-13-how-to-deploy-production-grade-vpc-aws.adoc index d31acd72d..3bb73c29b 100644 --- a/_posts/2019-08-13-how-to-deploy-production-grade-vpc-aws.adoc +++ b/_posts/2019-08-13-how-to-deploy-production-grade-vpc-aws.adoc @@ -610,7 +610,7 @@ Infrastructure as Code Library. [[pre_requisites]] === Pre-requisites -This walkthrough has the following pre-requistes: +This walkthrough has the following pre-requisites: Gruntwork Infrastructure as Code Library:: This guide uses code from the https://gruntwork.io/infrastructure-as-code-library/[Gruntwork Infrastructure as Code Library], as it diff --git a/_posts/2019-08-26-how-to-use-gruntwork-infrastructure-as-code-library.adoc b/_posts/2019-08-26-how-to-use-gruntwork-infrastructure-as-code-library.adoc index fb8ed7f46..21db1b119 100644 --- a/_posts/2019-08-26-how-to-use-gruntwork-infrastructure-as-code-library.adoc +++ b/_posts/2019-08-26-how-to-use-gruntwork-infrastructure-as-code-library.adoc @@ -278,7 +278,7 @@ _The Production-Grade Infrastructure Checklist_: | Bash, Chef, Ansible, Puppet | Provision -| Provision the infrastructure. Includes EC2 instances, load balancers, network topology, security gr oups, IAM permissions, etc. +| Provision the infrastructure. Includes EC2 instances, load balancers, network topology, security groups, IAM permissions, etc. | Terraform, CloudFormation | Deploy @@ -1049,7 +1049,7 @@ Configure variables:: This is similar to the `testing/terraform.tfvars` used in manual testing. Configure the backend:: - This is similar to tthe `testing-backend.hcl` used in manual testing. + This is similar to the `testing-backend.hcl` used in manual testing. Namespace resources:: The code uses `random.UniqueId()` to generate unique identifiers for all the resources in this test. This allows @@ -1426,7 +1426,7 @@ Use TFC without Terragrunt:: Use TFC with Terragrunt:: Alternatively, you can use both `infrastructure-modules` and `infrastructure-live` repositories as described above, - storing the wrapper modules in `infrastructure-modules`, and using `infastructure-live` and Terragrunt for + storing the wrapper modules in `infrastructure-modules`, and using `infrastructure-live` and Terragrunt for deployments. In this approach, TFC is used as a https://www.terraform.io/docs/backends/types/remote.html[remote backend] for Terraform. You use Terragrunt to run deployments from the CLI, which in turn invokes Terraform on the TFC backend. The TFC UI is used for audit and tracking capabilities, but not for executing Terraform runs. @@ -1708,9 +1708,9 @@ There are a few ways to set these credentials: . Create all the workspaces manually in advance, and set the `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` in each workspace, as described in <>. . Create all the workspaces manually by running `terragrunt init`, and still set up the environment variables as previously mentioned. -. To set this up programatically, you can use the https://www.terraform.io/docs/providers/tfe/r/workspace.html[`tfe_workspace`] and https://www.terraform.io/docs/providers/tfe/r/variable.html[`tfe_variable`] resources to configure the workspaces with Terraform. +. To set this up programmatically, you can use the https://www.terraform.io/docs/providers/tfe/r/workspace.html[`tfe_workspace`] and https://www.terraform.io/docs/providers/tfe/r/variable.html[`tfe_variable`] resources to configure the workspaces with Terraform. -In all cases, you'll need to ensure that your workspaces stay in sync with your Terragrunt configuration. Each time you add a new module in Terragrunt, you'll need a corresponding workpace. Furthermore, if you rotate your AWS API keys, you'll need to update them within each workspace. For that reason, the final option above is recommended. +In all cases, you'll need to ensure that your workspaces stay in sync with your Terragrunt configuration. Each time you add a new module in Terragrunt, you'll need a corresponding workspace. Furthermore, if you rotate your AWS API keys, you'll need to update them within each workspace. For that reason, the final option above is recommended. ===== Setting variables diff --git a/_posts/2019-09-03-how-to-deploy-production-grade-kubernetes-cluster-aws.adoc b/_posts/2019-09-03-how-to-deploy-production-grade-kubernetes-cluster-aws.adoc index 41f7f5eaa..1e28377ac 100644 --- a/_posts/2019-09-03-how-to-deploy-production-grade-kubernetes-cluster-aws.adoc +++ b/_posts/2019-09-03-how-to-deploy-production-grade-kubernetes-cluster-aws.adoc @@ -473,7 +473,7 @@ files—with the main difference being that: * Kubernetes stores Secrets in an encrypted form in etcd. + NOTE: https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/[etcd encryption] is only available as of -Kubernetes 1.13 and not available out of the box on all Kuberentes platforms (older versions of Kubernetes stored +Kubernetes 1.13 and not available out of the box on all Kubernetes platforms (older versions of Kubernetes stored secrets unencrypted!). === Options for running Kubernetes in AWS @@ -830,7 +830,7 @@ using the Gruntwork Infrastructure as Code Library. [[pre_requisites]] === Pre-requisites -This walkthrough has the following pre-requistes: +This walkthrough has the following pre-requisites: Gruntwork Infrastructure as Code Library:: This guide uses code from the https://gruntwork.io/infrastructure-as-code-library/[Gruntwork Infrastructure as Code Library], as it @@ -899,7 +899,7 @@ module "vpc" { num_nat_gateways = var.num_nat_gateways } -# ... (the rest of the code is ommitted) ... +# ... (the rest of the code is omitted) ... ---- Update this module to use the @@ -933,7 +933,7 @@ module "vpc_tags" { eks_cluster_name = var.eks_cluster_name } -# ... (the rest of the code is ommitted) ... +# ... (the rest of the code is omitted) ... ---- Add a new input variable that you can use to specify the name of the EKS cluster: @@ -1197,7 +1197,7 @@ variable "cluster_min_size" { } variable "cluster_max_size" { - description = "The maxiumum number of instances to run in the EKS cluster" + description = "The maximum number of instances to run in the EKS cluster" type = number } @@ -1732,7 +1732,7 @@ module "iam_policies" { iam_policy_should_require_mfa = false trust_policy_should_require_mfa = false - # If your IAM users are defined in a separate AWS accounth (e.g., a security account), you can pass in the ARN of + # If your IAM users are defined in a separate AWS account (e.g., a security account), you can pass in the ARN of # of that account via an input variable, and the IAM policy will give the worker nodes permission to assume that # IAM role allow_access_to_other_account_arns = [var.external_account_ssh_grunt_role_arn] diff --git a/_posts/2019-10-17-how-to-achieve-cis-benchmark-compliance.adoc b/_posts/2019-10-17-how-to-achieve-cis-benchmark-compliance.adoc index d88c154b0..1d57331df 100644 --- a/_posts/2019-10-17-how-to-achieve-cis-benchmark-compliance.adoc +++ b/_posts/2019-10-17-how-to-achieve-cis-benchmark-compliance.adoc @@ -612,7 +612,7 @@ Infrastructure as Code modules from Gruntwork. [[pre_requisites]] === Pre-requisites -This walkthrough has the following pre-requistes: +This walkthrough has the following pre-requisites: Gruntwork Infrastructure as Code Library:: This guide uses code from the link:https://gruntwork.io/infrastructure-as-code-library/[Gruntwork Infrastructure as Code Library], as it @@ -642,10 +642,10 @@ Terraform:: === The Gruntwork solution Gruntwork offers battle-tested infrastructure as code modules to help you create production grade infrastructure in a fraction of the time it would take to develop from scratch. Each of the code modules are "compliance-ready"; they are -mostly unopionated by default, but they can be configured for compliance with the right settings. +mostly unopinionated by default, but they can be configured for compliance with the right settings. To further simplify and expedite compliance, the Gruntwork Compliance modules are "wrappers" around the core, -unopionated modules in the Infrastructure as Code Library. The wrappers call the core modules with configuration values +unopinionated modules in the Infrastructure as Code Library. The wrappers call the core modules with configuration values that are compliant with the AWS Foundations Benchmark. You can use the wrapper modules by creating a module of your own (this can be considered a second wrapper) and using the compliance module as the `source`. Optionally, you can also use `terragrunt` to call your module, thus creating a chain of IaC modules. @@ -680,7 +680,7 @@ The `infrastructure-modules` are your organization's "blueprint" for how to depl use `infrastructure-modules` to customize the settings according to the needs of your environment. Subscribers can refer to the canonical link:https://github.com/gruntwork-io/infrastructure-modules-multi-account-acme[ACME infrastructure-modules -reposistory] for an example of how you might use `infrastructure-modules`. +repository] for an example of how you might use `infrastructure-modules`. If you're using Terragrunt, the `infrastructure-modules` are optional; you can call the compliance wrapper modules directly as the `source` from a Terragrunt configuration. The benefit of this is that you have less code to maintain by depending directly on Gruntwork's upstream compliance modules. @@ -917,7 +917,7 @@ compliance. If you are using multiple AWS accounts, create users in a central AWS account that you wish to use for authentication. For example, you might use a "security" account for authentication, and use the previously created cross-account roles and associated IAM groups to enable users to use AssumeRole to access other -accounts (e.g. dev, stage, and prdouction) where your applications run. +accounts (e.g. dev, stage, and production) where your applications run. (Optional) Create custom IAM groups or roles:: If you need to create customized IAM groups and/or roles, use the diff --git a/_posts/2020-02-06-how-to-configure-a-production-grade-ci-cd-setup-for-apps-and-infrastructure-code.adoc b/_posts/2020-02-06-how-to-configure-a-production-grade-ci-cd-setup-for-apps-and-infrastructure-code.adoc index 3f1971bc3..825ffd779 100644 --- a/_posts/2020-02-06-how-to-configure-a-production-grade-ci-cd-setup-for-apps-and-infrastructure-code.adoc +++ b/_posts/2020-02-06-how-to-configure-a-production-grade-ci-cd-setup-for-apps-and-infrastructure-code.adoc @@ -1,5 +1,5 @@ --- -title: How to configure a production-grade CICD workflow for infrastructure code +title: How to configure a production-grade CI/CD workflow for infrastructure code categories: Automations image: /assets/img/guides/infrastructure-cicd-pipeline/terraform-icon.png excerpt: Learn about CI/CD workflows for Terraform and Terragrunt, including the differences between application code, different CI servers, threat models, and more. @@ -646,7 +646,7 @@ mitigation tactics for those threats. This is where threat modeling helps. A threat model explicitly covers what attacks are taken into consideration in the design, as well as what attacks are __not__ considered. The goal of the threat model is to be realistic about the threats that are addressable with the -tools available. By explicitly focusing attention on more likely and realistic threats, we can avoid overengineering and +tools available. By explicitly focusing attention on more likely and realistic threats, we can avoid over-engineering and compromising the usability of the solution against threats that are unlikely to exist (e.g., a 5 person startup with 100 end users is unlikely to be the subject of a targeted attack by a government agency). @@ -1133,7 +1133,7 @@ infrastructure-live === Deploy the ECS Deploy Runner -// TODO: update link to use service catalog so it is publicly visiable +// TODO: update link to use service catalog so it is publicly visible For this guide, we will use https://github.com/gruntwork-io/module-ci/blob/master/README-Terraform-Terragrunt-Pipeline.adoc[Gruntwork's ECS Deploy Runner stack] as our infrastructure deployment CD platform. We will deploy the stack into the private subnet of our @@ -1621,7 +1621,7 @@ Repeat for each environment that you want to support the ECS Deploy Runner stack At this point, you can see if the ECS Deploy Runner can be used to deploy your infrastructure. To test, use the https://github.com/gruntwork-io/module-ci/tree/master/modules/infrastructure-deployer[infrastructure-deployer CLI]. -To use the `infrastructure-deployer` CLI, use `gruntwork-install` to install a precompiled version for your system: +To use the `infrastructure-deployer` CLI, use `gruntwork-install` to install a pre-compiled version for your system: [source,bash] ---- diff --git a/rfc/cta-rfc.md b/rfc/cta-rfc.md index aa66029bc..2e817f8fd 100644 --- a/rfc/cta-rfc.md +++ b/rfc/cta-rfc.md @@ -21,7 +21,7 @@ - We cannot have different styles applied for different webpages. . It stays uniform -- The same teammates show on all pages. It cannot be edited based on different webpages but if we want to change the routes of where conversations go based on cusomers starting a conversation, we could setup Assignment Rules from the Start a conversation button. There we would be able to route customers to different inboxes or teammates based on their keywords, attributes and or the webpage they are visiting from. We will need to upgrade to Inbox Pro to use this feature. More on this [here]() +- The same teammates show on all pages. It cannot be edited based on different webpages but if we want to change the routes of where conversations go based on customers starting a conversation, we could setup Assignment Rules from the Start a conversation button. There we would be able to route customers to different inboxes or teammates based on their keywords, attributes and or the webpage they are visiting from. We will need to upgrade to Inbox Pro to use this feature. More on this [here]() - We cannot use GA tracking to track the buttons clicked @@ -39,5 +39,5 @@ - All we are trying to implement has already been implemented by intercom and even better. -#### Conclusion +#### Conclusion We should go with the existing intercom and make some changes so it can go live. diff --git a/rfc/guides-comments.md b/rfc/guides-comments.md index 97608a060..78cc3cc5d 100644 --- a/rfc/guides-comments.md +++ b/rfc/guides-comments.md @@ -1,15 +1,15 @@ - + ## RFC for Adding Comments to our Deployment Guides - + Options available for adding comments to the deployment guides are as follows: ### Disqus: - + Really good third party service and the most popular. It has 3 options: -- Basic: This has ad's (not recommendxed) +- Basic: This has ad's (not recommended) - Plus $9 per month (Suitable for under 50k visitors daily) - Pro $89 per month (Suitable for 150k visitors daily) @@ -65,7 +65,7 @@ Also a third party service and very similar to Disqus #### Cons: 1. Staticman must access to our Jekyll repository 2. Spamming- There is no form of authentication. - + > N/B We have to be careful of XSS attacks.. ### Gitment [https://github.com/imsun/gitment](https://github.com/imsun/gitment) @@ -99,4 +99,4 @@ Ref: https://robb.sh/posts/comments-utterances/ ### Conclusion: -I think we can either use Utterances or Staticman. If we are more focused on a broader audience commenting on the posts not restricted to only github users, then staticman will be our best pick. \ No newline at end of file +I think we can either use Utterances or Staticman. If we are more focused on a broader audience commenting on the posts not restricted to only github users, then staticman will be our best pick.