Cloud GIT Hosting
Colleagues,
Recently, a cloud hosting project for Git has been launched into public beta: www.elasticgit.com
In this article - overview - I will tell about plans, architecture and technologies.
')
GIT is a fairly popular source management system and I assume that most readers are familiar with it. Many are already “happy” users, many understand what it is thanks to numerous publications on Habré. And perhaps the vast majority know about the site GitHub.com - super convenient hosting of many open-source projects.
Having years of experience with Git in the corporate sector, at some point a sufficient amount of in-house development has accumulated, which can be easily turned into a public service. So, meet - elasticgit.com
I tell you about the concept; in perspective, three levels of service are expected
But this is all in the plans - and at the moment item number one is working - cloud hosting.
Let's discuss why the service is “cloudy”. When we talk about clouds - as a rule, we imagine the availability of resources not as a constant, but as a variable - variable depending on the needs of the system (load and mn).
ElasticGIT is built on this principle - we do not have hosting packages: X repositories, Y users. It is not at all clear what to do, say a team of 5 people, but with 50 repositories and 50 people with 5 repositories. Therefore, ElasticGIT works on the basis of the resources consumed: how many repositories are created, how much disk space and traffic is used per month.
At the same time, we are not going to put a limit on the number of users - because if the user does not work with the system, then he does not consume any resources.
In general, the issue of pricing policy is not worked out and therefore I can not provide a lot of information - but our calculations show that most teams will stay within 2 dollars per month.
At the stage of Public Beta, each account gets up to 20 repositories, 100 MB of disk and 1GB of traffic - although all limits can be changed with real need (although so far it is unlikely to be operational).
A little about the platform itself.
Architecturally, the system consists of several levels: front, hosting-master, farms.
A farm is a server on which client data is actually stored. Of course, there are many such servers and they can be grouped into villages. Groups are like namespaces — and by dividing clients we can optimize repository policies. From a technical point of view, all the farms are the same - their software can backup and restore itself and also understands the hosting-master commands.
Hosting master is the accounting system of “everything” - it is accessible by API and manages all villages + farms. This is where the access data, keys, etc.
Front is our public web server. In fact, this is a wrapper for easy API calling from hosting-master.
And some more details
1. The system lives in Amazon Web Services - although there is no binding to this particular provider.
2. Developed its own version of the SSH server - to optimize management and system support
3. Developed its own version of GIT (server). Of course, this does not impose any restrictions on customers - 100% protocol compatibility
4. Front is Drupal 7 + custom modules
5. Business logic written in java (j2ee)
As I already said, the system is in the public beta mode - and it can already be used for non-critical projects. At the moment, an automatic backup system is being tested, so in case of a disk loss on the farm, it’s not a fact that we can restore everything. Sometimes the system can go offline - follow our twitter: @elasticGIT
So:
100MB
20 repositories
1GB traffic
Any number of users
To get started, you need to register or log in via Google / openid. In step two, add your public key and you can create repositories.
The paths will be: test@source.elasticgit.com: myrepo.git and, accordingly, clone can be done:
Questions and suggestions at support@elasticgit.com
And Twitter - in which we will make the most important updates
If the topic is interesting, I am ready to write a number of articles on technology.
Recently, a cloud hosting project for Git has been launched into public beta: www.elasticgit.com
In this article - overview - I will tell about plans, architecture and technologies.
')
GIT is a fairly popular source management system and I assume that most readers are familiar with it. Many are already “happy” users, many understand what it is thanks to numerous publications on Habré. And perhaps the vast majority know about the site GitHub.com - super convenient hosting of many open-source projects.
Having years of experience with Git in the corporate sector, at some point a sufficient amount of in-house development has accumulated, which can be easily turned into a public service. So, meet - elasticgit.com
I tell you about the concept; in perspective, three levels of service are expected
- For individual developers, teams and companies willing to store the code with the provider - the most standard type of service - source code hosting.
- If you want to store the code on your own server - we suggest downloading our software and installing it in your data center.
- Perhaps the most interesting: a set of API for integrating hosting into your application or service. And immediately give an example - you are the owner of a web service for project management. By simple integration, your customers will receive a new service - git hosted. Of course, the entire management interface will be presented on your website.
But this is all in the plans - and at the moment item number one is working - cloud hosting.
Let's discuss why the service is “cloudy”. When we talk about clouds - as a rule, we imagine the availability of resources not as a constant, but as a variable - variable depending on the needs of the system (load and mn).
ElasticGIT is built on this principle - we do not have hosting packages: X repositories, Y users. It is not at all clear what to do, say a team of 5 people, but with 50 repositories and 50 people with 5 repositories. Therefore, ElasticGIT works on the basis of the resources consumed: how many repositories are created, how much disk space and traffic is used per month.
At the same time, we are not going to put a limit on the number of users - because if the user does not work with the system, then he does not consume any resources.
In general, the issue of pricing policy is not worked out and therefore I can not provide a lot of information - but our calculations show that most teams will stay within 2 dollars per month.
At the stage of Public Beta, each account gets up to 20 repositories, 100 MB of disk and 1GB of traffic - although all limits can be changed with real need (although so far it is unlikely to be operational).
A little about the platform itself.
Architecturally, the system consists of several levels: front, hosting-master, farms.
A farm is a server on which client data is actually stored. Of course, there are many such servers and they can be grouped into villages. Groups are like namespaces — and by dividing clients we can optimize repository policies. From a technical point of view, all the farms are the same - their software can backup and restore itself and also understands the hosting-master commands.
Hosting master is the accounting system of “everything” - it is accessible by API and manages all villages + farms. This is where the access data, keys, etc.
Front is our public web server. In fact, this is a wrapper for easy API calling from hosting-master.
And some more details
1. The system lives in Amazon Web Services - although there is no binding to this particular provider.
2. Developed its own version of the SSH server - to optimize management and system support
3. Developed its own version of GIT (server). Of course, this does not impose any restrictions on customers - 100% protocol compatibility
4. Front is Drupal 7 + custom modules
5. Business logic written in java (j2ee)
As I already said, the system is in the public beta mode - and it can already be used for non-critical projects. At the moment, an automatic backup system is being tested, so in case of a disk loss on the farm, it’s not a fact that we can restore everything. Sometimes the system can go offline - follow our twitter: @elasticGIT
So:
100MB
20 repositories
1GB traffic
Any number of users
To get started, you need to register or log in via Google / openid. In step two, add your public key and you can create repositories.
The paths will be: test@source.elasticgit.com: myrepo.git and, accordingly, clone can be done:
git clone test@source.elasticgit.com:myrepo.gitQuestions and suggestions at support@elasticgit.com
And Twitter - in which we will make the most important updates
If the topic is interesting, I am ready to write a number of articles on technology.
Source: https://habr.com/ru/post/128609/
All Articles