Is there a way to run and debug a solution with custom pre-existing docker-compose and DOCKERFILEs when migrating to Visual Studio?
I'll try to elaborate as requested:
I'm working on a .Net Core project with multiple services (web APIs), each one with a respective DOCKERFILE. The containers and their dependencies are built and run via a compose file which is used for CD purposes and is optimized for our needs, but I can't use it together with VS2019 because the IDE doesn't recognize these files, and forces the creation of a new docker-compose (in the solutions' root folder) and DOCKERFILE when I attempt to add orchestrator support to any of the projects. These behavior results in the error message "the file ./docker-compose.yml already exists" and the creation of the docker-compose project fails (I'm following the instructions from here: https://learn.microsoft.com/en-us/visualstudio/containers/tutorial-multicontainer?view=vs-2019)
I don't want pollute my repository with the files generated by Visual Studio, but the naming convention used by the IDE makes ignoring them not as simple as it should (IMHO).
So, my question is, is it possible to use a custom docker-compose and DOCKERFILEs when adding container orchestrator support to my projects in Visual Studio?
Related
I've switched to using Visual Studio Code and and am missing the ability to right-click and publish files.
I read here that a task runner can be used to build/deploy files...
Publish Web Deploy using VS Code
That answer only mentions Grunt and I cannot find any articles on how to do this with Gulp which I am already using. I've got as far as finding an article on how to hook up Gulp and MSbuild which I assume must be the first step.
However, I'm unsure about the deployment step as I don't know what the "publish" button in standard VS does. It seems to be using something called MSDeploy or "web deploy" and requires a bunch of publish settings, so presumably this can be done from gulp?
I know I must sound a bit clueless but I'm not really a Microsoft guy I'm a front-ender, just happen to be working with other people's .net projects occasionally. Any help would really be appreciated.
WebDeploy is the technology that VisualStudio uses for web deployments. WebDeploy uses MSDeploy behind the scenes. MSDeploy is capable of far more than just web app deployments. We use it for deploying Windows Services, Scheduled Tasks and SQL databases as well.
Here are details on you to use the MSDeploy commandline. The sync command is used most commonly for deployments.
You can use the gulp-mswebdeploy-package plugin to create a web deploy package as part of you gulp build task. you can the use the msdeploy command line to deploy the site.
Over the last few months I've become familiar with the AWS OpsWorks deployment process as it pertain to Node.js - deployment for Go seems to be another animal.
From what I've gathered, this is what I need to compile a successful Go deployment:
Install go on the EC2 box
Pull the private repository from GitHub
Pull in all dependencies
Compile the main package for the box's arch
Start the binary with a couple of flags that I use
Everywhere I have read seems to tout the ease of Go deployments because dependencies are included in the binary, but that seems to imply that you are compiling the application in your development environment and pushing that up to the cloud. This doesn't seem like a process that works well across a development team.
https://github.com/crowdmob/chef-golang-web-server-cookbook
I have been attempting to get the Chef Scripts from CrowdMob working, but to no avail. I continue to get errors that look like this:
[2014-08-01T16:08:22+00:00] WARN: Cookbook 'templates' is empty or entirely chefignored at /opt/aws/opsworks/current/merged-cookbooks/templates
What is the proper way to deal with dependencies during deployment?
Are there any established practices for deploying Go onto AWS with Chef?
Use a continuous integration service like CircleCi, Travis or your own setup Jenkins.
On the Continuous integration service then
Add a github post commit hook .
Test / Build the binary
Create the zip file as artifact
At this point you can create an new version on Elastic Beanstalk using the AWS commandline and the zip file created from this version.
venv/bin/aws elasticbeanstalk create-application-version ...
Then just select which version to deploy from the EB dashboard.
For simple services using Chef is overkill IMHO. Docker offers a simple workflow.
Use the Docker container option and then use elastic beanstalk's command-line client to initialize your environment in the project root directory and then you can simply do a 'git aws.push' from the same place.
With the correctly configured Dockerfile in your project and pushed to eb, the EBS' docker container app will pull the correct image with golang installed, then do a go get on your projects dependencies, and then compile and run your app. It sounds way more complicated but it's actually very easy.
Below is a link to a video walkthrough I did for running a simple golang webapp on EBS. The method for uploading the project does not use git. Instead, I zip it up and upload it, but the git method is recommended (and I do it) for automating deployment.
YouTube: How to run a go web app on Amazon's Elastic Beanstalk
I also had some problems to setup a good building process with Elastic Beanstalk and Go.. I don't want to use Docker, and all the people seems to be going on this direction.. so.. you can take a look at this project: https://github.com/battle-arena/heimdall
There you will find a custom setup using the Buildfile and the Procfile.. and I rely on a CI system to build the release package...
Basically I do the following:
Hook the commits to a CI system
On the CI system I run the test and the install.sh if all good
The install.sh will create a build folder and a structure that will be sended to the Elastic Beanstalk with the aws-cli tool
After send to the EB the Buildfile will run the build.sh that will basically extract the compressed package with the proper structure, and run a go get ./... and go build
The Procfile will run the generated binary
I think the result is pretty good, and you can use with any CI tool.
I'm very new to TFS but am using Visual Studio Team Services... which i believe are largely the same configurations and technologies.
Now its possible that VS Team Services only supports web projects but they to be the only type of project that i'm able to build. I've tried several other (non-web) project types including the default console project but I always get a build error similar to one below....
C:\Users\Mark\Documents\Visual Studio 2013\Projects\App1\App1\App.config:
Access to the path 'C:\Users\Mark\Documents\Visual Studio 2013\Projects\App1\App1' is denied.
I'll get a error like the one above for every file in the project.
Can someone confirm whether Visual Studio Team Services does support building other types of projects. If so, is there some special permission or additional setting in build definition that needs to be set prior to triggering build?
Thanks. Turns out all i needed to do was to switch the build template under Build Definition->Process--> Build Process file from default to 'TfvcTemplate.12.xaml'.
How do you handle the deployment of a LightSwitch application into a production environment?
i.e. the LS application has been developed, but it now needs to be installed first into Test, and then into Live.
We don't want to use the "manual" approach, i.e. use the Visual Studio Build / Publish option, rather we want to automate the deployment.
My feeling is that deployment is one of the real weak points of LightSwitch. If you are using the very simple deployment model that is build into the product, and you're doing everything within a Windows domain, the publishing wizard can do everything. But if you're deviating from the model at all LightSwitch will fight you. I'd really like to see an "advanced" deployment option that provided some configurability.
Here's how I solved the problem you're having with LightSwitch applications that are targeting web deployment:
At the beginning of the project, deploy once to each target environment using the publish wizard. This is the easiest way to get the database set up.
As new builds are deployed, use the publish wizard to deploy to a deployment package to a standard location on the local development machine.
The deployment package is just a zip file, so you can open it an drill down to where the actual binary release is. I use a powershell script to copy the binary files out of the the deployment package and in to a local SVN working directory. Note that you must not copy web.config file during this step.
Check the unpacked binary files into SVN and use SVN to manage the deployment.
Manage schema changes with SQL scripts.
With VisualStudio Publish, CruiseControl.NET, MSBuild, aspnet_compiler.exe, and Web Deployment Projects out there, how would one know which tool to use to ultimately get a .NET 2.0 web application into a testing/production environment?
With .NET 1.1, I simply copied all files over to the server's directory and set it to a configured virtual directory in IIS. Unless I am really missing something, it seemed to work just fine. Now I'm reading about how important it is to put some good thought into 2.0 deployment and the the more I read, the more I get confused.
Please breakdown how to choose which tool to use, and why you would use that tool. If more than one tool is needed, please identify how they relate to this process.
CC.NET is for Continuous Integration it can build your setup projects as artifacts, but that is not it's main purpose. MSBuild is the Microsoft build system -- again, not related to deployment. aspnet_complier compiles your web sties, which may make deployment easier, but is not in itself deployment.
Web deployment projects is what you should be looking at. Here's a decent little post that goes over some of the options for deployment and a reference from MSDN. There are also commercial products.
In most cases, you can right-click on project in VS.NET and choose "Publish". This will give you a few options for deploying via FTP or file path.
Publish Web http://img26.imageshack.us/img26/1261/screencfl.png
What we do it publish to an SVN repository, then run SVN UPDATE on the machines it needs to go to...
I use TeamCity, which implements
Rebuilding solution with
devenv.exe in command line
Changing settings in web.config
(connection strings and debug mode)
with sed.exe
Precompiling WebSite
with the aspnet_compiler in command
line.
Copying solution to FTP
(with internal tool)