This article is designated for experts, and expert meaning someone with many years of real DevOps technical experience, certifications, and true/real quantifiable technical experience. Meaning Windows Engineer, Developer, Linux Engineer, and Network Engineer.
The reason for this notation and criteria are because the essence of this article will NOT be a step-by-step as the subject matter could cover a small book.
Setting up Development on AWS w/ aMiSTACX
The reason we want to set up or recommend setting up are many! Security, control, central point of backups, standardization of design, and more. In fact, they way we will layout the high-level design is almost exactly what our developers and engineers work on projects. We also train our outside consultants on the same infrastructure.
Step 1. Spin up our deployment for Windows Server, Windows 2016 Server
This server has all the goodies to get started, and acts as the core foundation. It is set up with WinSCP, Putty, phpMyAdmin, MySQL, MySQL Client, phpStorm [trial version], Group Policy shortcut, and more.
Step 2. Create your developer accounts using the Windows Server Manager. Now this server only allows for two RDP connections, so it is limited. You can build your own RDP Application server to get around these constraints, but we found it just easier and faster to just clone the Windows server. Reason comes down to cost per hour of usage. As development normally does not take place 24/7/365, and when it does, just bring up the clones online – 2,4,6 😉
Note: Normally we just allocate user level privileges with remote desktop access to our developers.
Step 3. Setup IDE phpStorm. The way we do it, is we connect to the remote Linux Server as a remote project, and pull the files down into phpStorm. For example, let’s say we are working on Magento. We first deploy an aMiSTACX EC2 for Magento, then we pull the entire document root or subfolder into phpStorm.
Note: We set the storm framework to use PHP 8.x [or the latest possible]. We also use PPK keys for the SFTP storm connection. This is important for security reasons. You can test your storm to Linux server first with WinSCP or Putty.
Step 4. Because phpStorm uses the ubuntu user to connect, we preserve the security model, but need to do two more items for proper phpStorm SFTP deployments.
- Set document root to 775 www-data user/group
- Add ubuntu to www-data group ;
sudo usermod -a -G www-data ubuntu
Note: Make sure you have enough space on Windows, as a sync could be several GBs.
Step 5. Local Project folder creation. Normally we just create folder in the C:\Inetpub directory. This is a centralized way, and not as the documents folder per user. Also, we tighten security to just the developers that need access to the folder, and remove the user group. When storm asks for the destination of the project, this is what you will point to.
Step 6. After Remote and Local are sync’d, test remote deployment with a simple file. If there is an issue, see Step 4.
Note: Restrict Robots.txt on the remote server. Just in case during outside testing. More on that next.
Step 7. We set up Security Groups to limit inbound 3389 traffic to the RDP server, and then restrict outbound of the RDP server to specific IPs of the remote Linux Server. We tighten down even more by using a DNS security proxy to lockdown all traffic on outbound port 80/443. In fact, you really don’t need 80. Just: 443, 8080, 53 UDP, and 3306 for RDS Projects.
Inbound on the remote Linux server we do the same. Inbound is only from the RDP server, and outbound is usually restricted to only ports required.
Step 8. GIT – We set up GIT on the Linux Development server, and depending on the project, we use either AWS CodeCommit or Beanstalkapp. AWS CodeCommit is security limited, because it has no IP filter. Meaning anyone with your keys will have read access. Whereas BSA can restrict on keys and IP.
Tip! Set GIT filemode to false, and if you encounter file read issues, make sure LF endings are set to linux.
Normal Professional grade CI looks something like this:
- phpStorm insync with Linux remote Dev w/ GIT
- After deploy to remote, commit to GIT and push to remote Repo
- From stage server pull from GIT Repo
- After stage passes, then switch to Production and pull from Repo
Step 9. Extra Security – For our Development Environments we use Windows Group Policy to remove remote client drives, and in some cases prevent clipboard access. Group policy can lock things down to beyond belief. Enough to frustrate and annoy your devs lol.
Step 10. Even more Security – If you need outside testing or to pull items to the RDP Dev server, please consider an HTTPS proxy. Cisco OpenDNS is a great one. This way you can whitelist and get reports on inbound and outbound requests. Plus, this helps keep your RDP dev server free from any malware 😉 Seriously, devs just love to download stuff and not think twice.
Step 11. Bonus! When using A51 to manage your entire AWS aMiSTACX environment, you can add team members to the A51 console. This way when they need access to the RDP server, they can start it, and when finished, just stop it. Stopping = no EC2 charges and increased security. [You can also assign A51 Power Groups to your developers, and reduce costs.]
Additionally, you can easily control all of this from your phone 😉 So you can start the RDP server for the devs, and stop it when finished, or be alerted when the server starts. This is NOT micro management! This is smart management. Reduction of AWS hosting costs & Increased Security.
All of this security with A51 Monitoring & Control, will help the you the business owner sleep better at night.
~ Lead_Robot