We have AWS on board to publish a Quick Start guide for GitLab on AWS. The QuickStart guide is a production-ready deployment of a product, so this is an excellent vehicle for our customers to start using GitLab.
“I agree that I am licensing Amazon to modify and use all content provided as part of the [insert project/service name/technology] Quick Start project. Code (including CloudFormation and associated scripts and files) is provided to Amazon under the Apache License 2.0. Documentation is understood to be a joint work between Amazon and my employer, and will be published by Amazon under copyright with attribution of my employer."
As soon as the page is live, AWS will organize launch activities including:
What’s new page on the AWS website (example)
Social media (Facebook, Twitter, LinkedIn)
AWS internal announcement
Announcement on the Quick Start forum
Optional blog post (e.g., APN blog or Jeff Barr’s blog)
A Solutions Architect from our supporting team can join us for an on-stage speaking engagement or at an event we choose, support our booth to cover our quick start guide
@axil the images are being maintained by the build team, specifically @balasankarc has been working on automating them.
Before him I took my hand at rolling them out and the document that you referenced is correct. Our install process is to spina machine, download the GitLab Omnibus installer, install it, and then shutdown the machine and create an AMI. This leaves it so that all that needs to happen is the end user launches an instance from our AMI, configured the gitlab.rb with their settings, runs gitlab-ctl reconfigure and they're off to the races.
Clearly we cannot list them all, so we need to be selective and then link to our pages for the rest. We also have to include both CE and EE, so I was thinking to first list 2-3 main features both versions share, for example CI, and then talk a bit more of the EE offerings.
Geo unfortunately cannot be listed as this is a quick set up guide to get you started with one instance, whereas Geo includes many manual steps and a secondary server.
Here's what I have till now:
GitLab is an on-premises Git repository management platform which, among
others, unifies issues, code review, CI and CD into a single UI. It comes
in two flavors: GitLab Community Edition which is free and open source
and GitLab Enterprise Edition the proprietary offering which builds on
top of Community Edition with extra features and requires a license. Both
editions provide the following features:
Built-in Continuous Integration and Continuous Deployment:
GitLab CI splits builds over multiple machines, for fast execution.
With autoscaling you can automatically spin up and down VM's to make sure
your builds get processed immediately and minimize costs.
Issue Boards
If you choose to use GitLab Enterprise Edition, the following extra
features will be available:
@eliran.mesika if I'm correct about my assumptions I'm blocked to fully provide the quick start guide.
It seems the guide assumes a CloudFormation template is in place, but we don't have any. The template would glue several AWS components together and the user could easily use it to provision a GitLab instance.
@axil I can find our AMIs under "Community AMIs" while creating a new instance. Like @northrup pointed out, with our AMIs, users only have to do the following
Create an instance with our AMI
Edit gitlab.rb and set necessary values (external_url at least)
Run gitlab-ctl reconfigure.
This was the initial plan that was discussed before AMI creation was automated.
@eliran.mesika If I am not mistaken, what we need is a way to get these existing AMIs to Marketplace. Right?
@axil Regarding architecture, postgres and NFS, I think someone from Infra team can answer better. My knowledge regarding that ends with a single server for everything with ufw for security.
@axil it seems we do need a CloudFormation template for this one. I've added their documentation link to the description as well: https://aws-quickstart.github.io/
@balasankarc do you know how to make a CloudFormation template?
@eliran.mesika do you know how easy it is for us to iterate on this? Does this require manual marketing effort by Amazon or can we update this as needed by ourselves once we're part of the program?
Would be good to know if we can iterate on this and add features over time (weeks) or if we should wait until we have a more complete solution with HA, etc.
@joshlambert@eliran.mesika I don't see it explicitly called out in the description, so can we make sure that this includes setting up a GitLab runner (or even an auto-scaling runner)?
@markpundsack I have been focused on getting the server up and running in the spirit of MVC, but adding a runner is definitely the next step. The time box was only a week, but if they have any time after the server is done will get the runner tee'd up. Frankly I'm a little concerned we will run out of time on the server by itself.
Worst case, it should be easy to add ourselves into the larger CFN framework and it would anyway be a good exercise to ensure we can maintain this going forward. We can start off with Shell and then move onto Docker Machine and the AWS driver.
@markpundsack update from our touchpoint today, we are making good progress on the core server. We will add the Runner as the next goal, provided we get the Server ready to go.
For now I think we focus on a standard Runner to get it included in the quickstart, and while that happens I will test out Docker Machine auto-scaling on AWS. AFAIK we haven't really documented that and want to make sure it all works first, and adding that support will just be a tweak to the installation script that runs.
Circling back on this, the Runner is included and it works. The only issue is that we currently have to ask for the Runner Token (20 char string) since AWS CF doesn't have an easy way to auto-generate this. (There is an open feature request)
The only other way I have seen someone do this is to provision a Lambda function just for this purpose, but that is out of scope of this first release.
Eliran Mesikachanged title from QuickStart Guide for AWS to AWS QuickStart Guide
changed title from QuickStart Guide for AWS to AWS QuickStart Guide
@joshlambert sure! We don't have time to figure things out though, at least until the end of September. After that, we could making this kind of things a priority.
If you have the steps clearly outlined and its a matter of pouring them in a guide-shaped form, we can do it before then.
From what I understand, we first need to create the CloudFormation template which is being tackled in omnibus-gitlab!1832 (closed). Once that's in, we can help :)
@aolson we're working with our third-party company to complete our CF template. Hoping to finish it by end of January. That would be available to use then, without the QuickStart at that point in time. We're working with AWS to see how we can submit GitLab in a way that is compliant with their requirements to have auto-recovery for all the components. If we'll be able to resolve that we will be able to publish the QS.
GitLab is moving all development for both GitLab Community Edition
and Enterprise Edition into a single codebase. The current
gitlab-ce repository will become a read-only mirror, without any
proprietary code. All development is moved to the current
gitlab-ee repository, which we will rename to just gitlab in the
coming weeks. As part of this migration, issues will be moved to the
current gitlab-ee project.
If you have any questions about all of this, please ask them in our
dedicated FAQ issue.
Using "gitlab" and "gitlab-ce" would be confusing, so we decided to
rename gitlab-ce to gitlab-foss to make the purpose of this FOSS
repository more clear
I created a merge requests for CE, and this got closed. What do I
need to do?
Everything in the ee/ directory is proprietary. Everything else is
free and open source software. If your merge request does not change
anything in the ee/ directory, the process of contributing changes
is the same as when using the gitlab-ce repository.
Will you accept merge requests on the gitlab-ce/gitlab-foss project
after it has been renamed?
No. Merge requests submitted to this project will be closed automatically.
Will I still be able to view old issues and merge requests in
gitlab-ce/gitlab-foss?
Yes.
How will this affect users of GitLab CE using Omnibus?
No changes will be necessary, as the packages built remain the same.
How will this affect users of GitLab CE that build from source?
Once the project has been renamed, you will need to change your Git
remotes to use this new URL. GitLab will take care of redirecting Git
operations so there is no hard deadline, but we recommend doing this
as soon as the projects have been renamed.
Where can I see a timeline of the remaining steps?