I am learning about CruiseControl.NET to implement continuous integration into my open source project. It looks like CruiseControl.NET will have to run on my personal computer, and it will build and execute new revisions automatically and immediately! It does not look like it would take a rocket scientist to hack a CruiseControl.NET server. Is it unsafe to use, or are there methods of securing it? For example, a super sandbox.
Generally, you can set up a master branch that you have commit access to and merge changes into that branch from others, so you can review code before commiting. Then give trusted members commit access to that branch to delegate code review before it reaches your testing branch.
You could probably (depending on the execution environment) also set up an execution jail to prevent rogue code from accessing restricted resources. Also, running tests as a restricted user helps.
So, my answer would be no, if you understand what's going on and can mitigate such risks.
Related
For about 18 months now I've been working in Node; and for the last 6 months I've been slowly migrating my existing WordPress websites to NextJS.
To date, I've been deploying to production manually. I log into my production server, checkout the latest release from GitHub, build, and do a pm2 restart.
Even though the above workflow seems to be the most commonly documented around the internet, it's always felt a little wrong to me.
Recently, I found myself in a situation where I needed to customise some 3rd party code. So, my main code now has a line in package.json that says
{
...
"dependencies": {
...
"react-share": "file:../react-share/react-share-4.4.1.tgz",
...
},
...
}
which implies that I'm going to checkout my custom react-share, build it somewhere on the production server, change this line to point to wherever I put it, and then rebuild.
Also, I'm using Prisma, which means that every time I deploy, before I do a build, I need to do an npx prisma generate to create the client.
This now all seems really, really wrong.
I don't know how a "simple" CI/CD environment might look, but whatever it looks like, it feels like overkill. It's just me doing development, and my production environment is a single EC2 server sitting behind AWS CloudFront.
It seems to me that I should be doing something more/different than what I'm currently doing, in service to someday moving to a CI/CD model, if/when I have a whole team working on this, or sufficient users that I have multiple load-balanced servers and need production to be continually up.
In particular, it feels like I shouldn't be building on the production server.
Are there any intermediary step(s) I can/should be taking for faster/less-error-prone/less-down-time deployment to a single EC2 instance for Next/Node apps, between manually deploying as I am currently, and some sort of CI/CD setup? Or are my only choices to do what I'm doing now, or go research how to do CI/CD?
You're approaching towards your initial stages of what technically is called DevOps, if not already as it appears from your context. What you're asking is a broad topic, which is an understatement, and explaining each and everything here will almost be like writing an article about it, at the very least.
However, I'll brief you overall on how to approach with this.
I don't know how a "simple" CI/CD environment might look, but whatever it looks like, it feels like overkill.
Simplicity & complexity are relative terms. A system which is complicated for one might be simple for another. CI/CD doesn't define any laws that you need to follow in order to create a perfect deployment procedure, as everyone's deployment requirement is unique (at some point).
If I mention it in bullet points, what you need to figure out before you start with setting up CI&CD, is -
The sequence of steps your deployment procedure needs in order to deploy your latest version. As you have stated already that you've been doing deployment manually, that means you already know your steps. All you need to do is to fine-tune each step so that it shouldn't require manual intervention while being executed automatically by the CI program.
Choose a CI program, like Travis CI, Circle CI, or if you're using GitHub, it has it's own GitHub Actions for the purpose, you can read their documentation for more details. Your CI program will be responsible for executing your deployment steps which you'll mention to it in whichever format it understands (mostly .yml).
The CI program will execute your steps on behalf of you based on the condition which you'll provide, (like when code is pushed on prod branch). It will execute the commands on a machine (like your EC2), specifically, GitHub actions runner will be responsible for running your commands on your machine, the runner should be setup beforehand in the instance you intend to deploy your code on. More details on runners can be found in relevant documentations.
Since the runner will actually execute the commands on your machine, make sure that all required commands and parameters, including the concerned files & directories are accessible to the runner program, from permissions point of view at least. For example, running your npx prisma generate command should require that npx command is available and executable in the system, and the concerned folders in which the command will CRUD files is accessible by the runner program. Similarly for all other commands.
Get your hands on bash scripting as well.
If your steps contain dynamic info, like the one you mentioned that in your package.json an npm script needs to be updated, then a custom bash script created to update the same automatically will help, for instance. There will be however, several other ways depending on the specific nature of the dynamic changes.
The above points are huge (by huge, I mean astronomically huge) oversimplification of the ways through which CI&CD pipelines are setup. But I hope you get the idea of it at least.
In particular, it feels like I shouldn't be building on the production server.
Your feeling is legitimate. You should replicate your production environment (including deployment procedures) into a separate development environment as close as possible, in order to have all your experiments, development and testing done separately from production environment, and after successful evaluation on the development environment, deploy on production one. Steps like building will most likely be done on both environments, as it is something your program needs to run, irrespective of the environment it is running in. Your future team will appreciate this separation of environments.
if/when I have a whole team working on this, or sufficient users that I have multiple load-balanced servers and need production to be continually up.
Again, this small statement in itself is a proper domain of IT department, known as System Design, in which, to put it simply, you or your team will create an architecture for your whole system which will support your business requirements and scaling as your audience increases, which is something a simple Stackoverflow QnA won't suffice to explain.
Therefore,
or go research how to do CI/CD?
is what I'd recommend and you should also feel is the right way ahead, after reading everything above.
Useful references to begin with (not endorsing any resources, you can search for relevant/better resources too)
GitHub Actions self-hosted runners
System Design - Getting started
Bash scripting
Development, Staging, Production
We're in process of adding Jenkins CI to a project with 100 developers.
Do you think they all need read-only access to Jenkins? or should it be accessed by 5 developers only who take charge of builds and continuous testing?
What could be reasons to let all developers login to Jenkins?
It's about security, auditing, Jenkins pipelines etc.
and technically (if relevant) it can be integrated with LDAP.
if 100 developers will be admin of Jenkins , I think that after several weeks someone will mess it up.
you should have several admins for it , to verify plugin before installation.
I used the role plugin , and define several roles for Jenkins :
admins
builders
configures
readers
team leaders ( with more permissions than configures)
There might be an easy technical solution to your problem: Jenkinsfile + pipelines
Then only one or two people need admin access for adding nodes and perhaps a password or two and some initial setup. Configuring the builds is done solely through a Jenkinsfile per repository.
That way, every developer with push access to the repo can configure the jenkins job for that repo. All in version control, so everyone will behave themselves.
LDAP/active directory integration is possible. In my setup, as an example, I've made login mandatory. Everyone that's logged in (=the developers) can stop/restart jobs. Only myself can do the rest of the maintentance. Very simple and clear and long-term-clean setup.
I want to know how developer continously develop a web application on cloud.
which software or which development environment they ae using?
Is Docker correct answer?
Thank you
This is an extremely open ended question, so I will give you a relatively open ended answer. CI/CD isn't really a defined process, but typically people follow the same strategy.
CI:
Develop and store code in Git or some repository
Execute unit test cases
Build Source Code
At this point, you have code that is being continuously tested and built. Now continuous delivery (CD) kicks in. This differs from company to company, but it may follow the below
CD:
Deploy Source Code to development integration testing server (DIT)
Execute Automated test portfolio
Deploy Source Code to Stage or Pre Prod environment
Execute Automated test portfolio
Now at this point in time you have your code fully tested and deployed to internal testing/stage servers. As a company, you can decide whether your confidence level is high enough to implement continuous deployment or if you implement a change mgmt process. continuous deployment is similar to continuous delivery EXCEPT you deploy the built application/service to production automatically with no gates in place. Then, you will run your test portfolio again against prod. Do not do performance testing in prod (do this testing in stage typically)
Product typically used for CI = Jenkins (open source, great community support)
Product(s) typically used for CD = Puppet, Chef, Ansible, uDeploy
Disclaimer - please do not get into a conversation about which products are best used for which stage...I only know what I know; and I know there are other tools to do CI/CD that I havent mentioned.
Our company uses ANT to automate build scripts.
Now somebody raised the question how to secure such build scripts agains (accidental or intended) threats?
Example 1: someone checks in a build script that deletes everything under Windows drive T:\ because that is where the Apache deployment directory is mounted for a particular development machine. Months later, someone else might run the build script and erase everything on T:\ which is a shared drive on this machine.
Example 2: an intruder modifies the default build target in a single project to scan the entire local hard disk. The Continuous Integration machine (e.g. Jenkins) is configured to execute the default build target and will therefore send its entire local directory structure to the intruder, even for projects that the intruder should not have access to.
Any suggestions how to prevent such scenarios (besides "development policies" or "do not mount shared drives")?
My only idea is to use chroot enviroments for builds?!
The issues you describe are the same for any code that you execute on the build machine - you could do the same thing using a unit test.
In this case the best solution may be to place your build scripts under source control and have a code review prior to check in.
At my company, the build scripts (usually a build folder) are an svn:external to another subversion repository that is only controlled by build/release engineers. Developers can control variables such as servers it can deploy to, but not what those functions do. This same code is reused amongst multiple projects in flight, and only a few devops folks can alter it, not the entire development staff.
Addition: When accessing shared resources, we use a system account that has only read access to those resources. Further: jenkins,development projects and build/deploy code are written to handle complete loss of jenkins project workspace and deploy environments. This is basic build automation/deploy automation that leads to infrastructure automation.
Basic rule: Murphy's law is going to happen. You should write scripts that are robust and handle cold start scenarios and not worry about wild intruder theories.
More and more server-side file deployments are handled using git. It's nice and there are plenty of guides available how to setup your deployment workflow with git, rsync and others.
However, I'd like to ask what's the cleanest way to set deployment rollbacks, so that
Every time you deploy, you record the latest state before the deployment (no need to manually read through logs to find the commit)
What git commands use to rollback to the prior (recorded) state in the case deployment has unforeseen consequences
The scope of the question is Linux servers, shell scripting and command line git.
Note that there is no general solution to this problem. I would propose two solutions.
First one requires usage of Fabric and some deep thinking how to handle whole deployment process. For a Django site I maintain, I wrote a fabric script that deploys staging on every git commmit. Deploying from staging to production is then a simple fabric command that copies all the files to a new folder (increments a version by 1), for example from production/v55/ to production/v56/ (ok, it also does backups and runs migrations). If anything goes wrong, rollback command restores backups, and starts production environment from folder production/v55. Less talk, more code: https://github.com/kiberpipa/Intranet/blob/master/fabfile.py
The second option requires more reading and has a bigger learning curve, but also provides cleaner solution. As Lenin suggested to use framework with declarative configuration, I would propose to go a step further and learn a Linux distribution with declarative configuration - http://nixos.org/. NixOS has built in capabilities for distributed software deployment (including rollbacks) and also tools to deploy stuff from your machine https://github.com/NixOS/nixops. See also thesis on Distributed Software Deployment, which covers also your questions (being part of a much bigger problem): http://www.st.ewi.tudelft.nl/~sander/index.php/phdthesis
Please have a look at Capistrano and Chef which require ruby/ror support. But are great deployment tools. Python's fabric is also an awesome tool.