I'm not altogether sure if there actually is a problem you're trying to solve, or whether you are looking for confirmation that you are on the right track. Some thoughts:
Internally openshift should be able to allocate dedicated pods
Sure. Add a post-build step in your CI pipeline which does the following:
Fashion a .yaml or .json description of that ...
Try LFTP that has commands to mirror or parallel copy. LFTP can run over many protocols.
The likely problem you have is that you are transfering a lot of data from a build service to a single vm over the Internet. Enterprises use the same tools and protocols but they pay for more bandwidth else ensure that their builds and deploy happens within the same ...
The things that would be backed up would be the config files of the servers, the database and uploaded content as these will almost always be unique and necessary. The containers, VMs, even the webapps would NOT be backed up as these should all be uniform and constantly updated under the CI/CD principles. Currently I use a combination of scp and tar into an ...
The .gitmodules file just records the path and remote URL to the submodule repository. The commit itself is stored in the tree object. You can query it like this:
git ls-tree <ref> <path>
where <ref> is a reference to some commit (e.g. HEAD, master, a commit SHA sum) and <path> is a path to a submodule.
The output looks something ...
Personally I'd keep them in separate repositories, for clear customer isolation:
minimal/no risk of unwanted interference between customers
different access control for different customers is possible
different CI/CD pipelines and/or configs for different customers is possible
simpler/standard CI/CD configurations
clean per-customer repository history
From spinnaker own documentation
Rosco is the bakery. It is used to produce machine images (e.g. GCE
images, AWS AMIs, Azure VM images). It presently wraps packer, but
will shortly be expanded to support additional mechanisms for
So yes, rosco uses HashiCorp's packer.
The main reason to use packer is that you just need to change ...
docker-compose up will remove containers when:
The service name is the same, but has a change, in which case the old container is replaced with the new state of the service
You include the --remove-orphans option when running docker-compose
Otherwise, if you change the name of the service, and do not specify --remove-orphans, you will see "orphaned" ...
Managing versions of different services can be tricky. For now I've never found a good HOW TO out there. Like most things you do what suit you the best. Here is a couple of suggestion you could use:
-> Tag docker image with their commit sha:
Pretty easy to do when you are using gitlab this is an already set environment variable that you can uses when ...
Both are excellent tools, but it depends on your use cases for which is better. I would highly recommend using the entire AWS Ci/Cd suite (CodeBuild/CodePipeline/CodeDeploy) to gain the full benefit of using your resources in AWS. Here are pros for both:
Multitude of customizability plugins
Integration with all cloud providers (GCP, Azure, etc.)
Merging code changes is definitely handled by Git and its tools. But Continuous Integration also includes testing and building the software. The development teams are provided with constant feedback on the status of their branch(es) and whether they are failing tests, builds, etc.
Jenkins provides the tools to enable this feedback. By creating a CI "...
AFAIK there are only 2 ways of deploying GAE apps:
using the gcloud app deploy command:
gcloud app deploy - deploy the local code and/or configuration of your
app to App Engine
using the Admin API. From Deploying Your Apps with the Admin API:
To deploy a version of your app with the Admin API:
Upload your app's resources to Cloud Storage.
Since on-premise TFS and the newly renamed Azure DevOps Server 2019 still have the concept of collections, which is the highest level of separation of data you can have (separate physical databases), you'd need to treat a code repo in Collection 1 as an external repository rather than try to discover it as a known internal repository.
You can do this in the ...
Not sure this helps you directly, but one option is to build the application within your CI build and push the (versioned) binaries/packages into an artifact repositorie like Sonatype Nexus or JFrog Artifactory.
Your build would then, in a later step pull these binaries from the target machine/from within the droplet.
There are many packaging formats, ...
Correct script below:
- apt-get install zip unzip
- yarn install
- ./node_modules/@angular/cli/bin/ng build --prod
- cd dist/AngularTemplate; zip -r ../../dist.zip *; cd ..; cd..
Was installing the wrong Zip package and then puttin my archive in the wrong folder.
It is safe. As soon as docker returns it is safe to logout/leave the shell.
The issue was that Docker 18.06.0-ce broke docker stack deploy. Reverting to 18.03.1 (specifically 18.03.1~ce-0~ubuntu) made it work.
Are you doing the building using web hooks or just polling? I think it's inevitable that you'll have to create a Jenkins account to manage API access. This Gitlab link explains how to use the Jenkins Gitlab plugin to manage building when changes are pushed. You'll see they use a Jenkins account as well. This is common practice in my organization to remove ...