Is there a way to reproduce Codeship's CI environment locally when not using Codeship's Docker support?
We don't share the build VMs for our classic infrastructure publicly at the moment. I'll bring this up with our engineering team, but I can't make any promises right now on what they'll decide.
We do however have a SSH debug feature available, that will allow you to access a build VM with your code cloned via SSH and run & tweak commands that way. See https://codeship.com/documentation/continuous-integration/ssh-access/ for more information.
Related
I need to provision a cloud 9 environment and run some provision scripts in it. Tried to do it with cloudFormation but found no way to ssh into it (without accessing the cloud9 terminal) nor to pass a script while bring cloud9 up.
My goal: setup several cloud nine instances for a workshop, which needs to run some scripts to work with it.
Any hints?
Auto-configuration is still a weak point for Cloud9 instances. What I've seen others do is create a script that is distributed to users and then ask them to run it in the terminal to setup the environment - not ideal but it works. I too would like to see a solution using CloudFormation or some other mechanism. Does this help?
You can have Cloud9 attach to any server via ssh after installing a few utilities. Thus, you can use whatever provisioning tools you want as long as your process includes adding those utilities.
I'm a junior web developer working in a small web agency. We work on windows 10, with wampserver and mainly with Prestashop, Wordpress and Symfony websites. For every task I am given a "ticket" for which I must develop on a new branch (if needed). When the work is done I merge my branch on the develop branch which is hosted on a preproduction server, and if it is considered ok, it is then merged on the master branch, which is the website in production hosted on another server.
I was given the task to do some research on Docker and to find how it could improve our workflow.
But from what I understood yet, docker containers are just similar to Virtual Machines and are only useful for building isolated environments in order to test an application without having to think about dependencies.
But given the fact that we already have a preproduction server, I don't see the point of using Docker ? Did I miss something ?
Also, could Docker be of use for sharing projects between teamworkers (we all work on Windows) ? (for example a developer is working on a website locally, can he create a container and its image that could be used instantly as it is without configurations by another developer to work on it on his part ?)
But from what I understood yet, docker containers are just similar to Virtual Machines and are only useful for building isolated environments in order to test an application without having to think about dependencies.
No, Docker containers are not only useful for testing.
When building a correct workflow with Docker you can achieve 100% parity between development, staging and production if all use the same docker images.
But given the fact that we already have a preproduction server, I don't see the point of using Docker ? Did I miss something ?
This pre production server, aka what is normally called a staging server should also use docker to run the code.
Also, could Docker be of use for sharing projects between teamworkers (we all work on Windows) ? (for example a developer is working on a website locally, can he create a container and its image that could be used instantly as it is without configurations by another developer to work on it on his part ?)
Yes... You create the base docker images with only the necessary stuff to run in production and from them you can build other docker images with the necessary developers tools.
Production image company/app-name:
FROM php:alpine
# other your production dependencies here
Assumming that ones build the docker image with name company/app-name then the image for development.
Development image company/app-name-dev:
FROM company/app-name
# add here only developer tools
Now the developer uses both images company/app-name and company/app-name-dev during development and in the staging server only company/app-name docker image will be used to run the code.
After soem months of interaction in this flow you may even fill confident to start using the company/app-name to deploy the app to production and now you are with a 100% parity between development, staging and production.
Take a look to the Php Docker Stack for some inspiration, because I built it with this goal in mind for my latest job, but I end up to leave the company when we where in the process of adopting it in development...
But don't put all services you need in one single docker image because that is a bad practice in docker, instead use one service per docker image, like one service for PHP, another for the database, another for the Nginx server, etc.. See here how several services can be composed together with docker compose.
I am trying to follow these instructions to us the Jenkins Plugin to create Jenkins agents with Azure Virtual Machines (via Azure ARM template).
Azure VM Agents plugin
Under Supported Features, it says:
Windows Agents on Azure Cloud using SSH and JNLP
For Windows images to launch via SSH, the image needs to be preconfigured with SSH.
I am a bit confused by this and I'm not sure what it means.
Does it mean that an SSH Client or Server should be installed on the Windows image?
There doesn't seem to be a option for setting up a Windows Azure VM with SSH access, as there is for a linux VM.
Please can anyone clarify what the set up process is?
(By the way, I have tried an unattended installation of cygwin on the Windows VM to try to run a SSH server, but I am running into a separate problem I am trying to solve. I'd like to know if this is not required.)
Answering my own question now I have got a bit deeper in. In the configuration section of the plugin, under Image Configuration, clicking the help on the launch method clarifies what's required.
It looks like a custom image needs to be custom-prepared with a SSH server pre-installed. However, it also looks like it is possible to launch an image with JNLP instead, so I will try that.
Update
I couldn't get JNLP to work (not sure why) but I did get SSH to work. Ticking the 'Pre-Install SSH in Windows Slave (Check when using Windows and SSH)' box does the trick. There's no need to pre-install on the custom image.
I tried to adopt Vagrant in our team. I created a Vagrantfile and make provisioning in some way. Everything works as charm, but ...
It's unclear for me how I can automate some routine tasks like:
running django(I use django, but it's framework agnostic problem) dev server on 0.0.0.0
running grunt watcher
providing a separate console for django-specific commands
It is looks like vagrant not intended to help with this kind of automation and I look for some community adopted way to do that. I goggled and found nothing.
I see a few way to that:
bootstrap.sh script but messy and hard to mantain
something like tmuxinator -- requires tmux on host machine and now it's impossible to put tmuxconfig in project repo
etc
What is the 'canonical' way to resolve this problem?
P.S.: Please, think about designers, manual testers and other guys which like to use tools as is
In general you are best off using a provisioner. To be honest, a bootstrap.sh file is a good place to start unless you want to learn the ins and outs of something like chef / ansible / salt / puppet. If you do you might want to start at salt (SaltStack) because it is written in python which I'm guessing you use given the django angle.
For your specific questions:
Part of the point of vagrant is it lets you develop against real stacks and real web servers so you can avoid the "oh, that don't quite work the same on apache" moment that often comes in projects. So for your first question I would look at how to provision the app behind apache / nginx or whatever you are using for the production web servers.
Because of the shared file systems users can just run grunt locally on the host machine. This also lets grunt do things like hook into OSX notifications.
I'm not familiar with tmuxinator so I'm not sure how to start here. But if it is a service that the server really runs then you should figure out a way to package the install and deploy it to the provisioned VM. As for configuration, is it possible to get a dev config in the repo?
Same as #Wyatt, I recommend use Vagrant with provision tools, such as puppet, saltstack, chef, anisble, etc. These tools are created for the requirements you ask for, and most are open source. Choice is no wrong, you can start learning from any one, they are similar.
With that, you can quickly and easily run several VM servers with all applications installed automatically. With the customised Puppet codes or chef cookbooks, you can update them any time and provision to VM easily, you can re-use them for your PROD environment as well.
Take some times to learn one of these automation tools first, you will get benefit to save a lot of time.
I use Puppet, and recommend the best puppet book PRO PUPPET to you. It has all you need.
I read about vagrant today, I have observed few points in it.
Vagrant creates a identical development environment for everyone in the team.
A modern, complex application probably uses a number of external dependencies, like various database servers, message queue etc. Installing these on every developer's machine individually for a local development environment can be quite a difficult. Using a virtual machine image, we can distribute a per-configured environment easily.
Have a 5 minute setup for any new developer who joins our team to get up and running. This should be as easy as running a single command: "vagrant up". No installation, no troubleshooting. It should “just work” ™
I have some queries on above statements,
How can we setup an environment for new member who joins our team?
In case new developer makes some changes in his virtual setup, how will it be reflected or deployed to your virtual setup?
Will you have to do the setup again? Or will it work as similar to SVN, namely, if one developer will change it will automatically affect the other machine also?
Vagrant is a good tool for manage teamwork and create a good startup flow..
You can create a git repository with your Vagrantfile and your provisioning script.. a new developer clone your repo and start it with "vagrant up" command.. And he is ready for work with complete env.
My configuration of Vagrant is a git repository.. I use it with normale VCS.
VCS :) git commit, pull, push ecc how a normal project..