I am packaging and in-house app as snap and would like to use our own intranet server to distribute it to clients. As much as I read the docs of snap, it seems it is documenting only distribution through official snapcraft.io channels. Is there a way to download a snap from URL?
Please note: I am not concerned about security in this question. I am also not asking about private snap repositories on 3rd-party servers.
Related
I'm new to web development and just built my first website with .Net Core. It's primarily HTML, CSS, and JavaScript with a little C# for a contact form.
Without recommending any service providers (question will be taken down), how do I go about deploying the website? The more details the better as I have no idea what I'm doing haha.
Edit: I am definitely going to go with a service provider, however the business I am building the website for doesn't have a large budget so I want to find the best provider at the lowest cost.
Daniel,
As you suspect, this is a bit of a loaded question as there are so many approaches. One approach is to use App Services within Microsoft Azure. You can create a free trial Azure account to start that includes a 200.00 credit, which is more than enough to do all of this for free. Then, using the Azure Management Portal, create an App Service (also free) on an App Service Plan in a region that makes sense for you (i.e. US West). Once you do that, you can download what is called a Publish Profile from within the App Service's Management Portal in Azure.
If you're using Visual Studio, for example, you can then right click your project and "Publish" it (deploy to the cloud, or the App Service you just created). One option in that process is to import an Azure Publish Profile, which you can do with the one you just downloaded. This makes it really simple. The Publish Profile is really just connection information to your Azure App Service (open it in Notepad to see). It will chug for a bit and then publish and load the app for you. You can also get to the hosted version of your app by clicking the Url of the app in the App Service management portal on the main page.
This may be oversimplifying what you need to do, but this is a valid direction to take. AWS and others have similar approaches.
Again, tons of ways to do this, but this is a free approach. :-) I don't consider Azure a Service Provider in the sense that you asked us not to. Instead, I wanted to outline one turn-key approach with specific details on how to get there.
You can find specific steps in a lot of places, such as this link:
https://www.geeksforgeeks.org/deploying-your-web-app-using-azure-app-service/
DanielG's answer is useful, but you mentioned you don't want use any services from service provider.
Usually, there are only three ways to deploy the program,
first one is the app service provided by the service provider mentioned by DanielG,
**Benefits of using service provider products:**
1. Very friendly to newbies, follow the documentation to deploy the application in a few minutes.
2. It offers a very stable, scalable service that monitors the health of our website.
3. We can get their technical support.
**Shortcoming**
It is a paid service, and although Azure's service has a free quota, it will run out.
**Suggestion**
It is recommended that websites that are officially launched use the services of service providers.
second one is to use fixed IP for access (it seems that fixed iPv4 IP is not provided in network operations),
**Benefits of using fixed IP:**
If there is a fixed IP address, or if the carrier supports iPv6, we can deploy our website, and the public network can access it. And if you have domain, it also can support https.
**Shortcoming**
1. There are cybersecurity risks and are vulnerable to attack.
2. Without perfect website health monitoring, all problems need to be checked by yourself, and it is very troublesome to achieve elastic expansion.
**Suggestion**
It is generally not recommended because there is no fixed IP under normal circumstances. Broadband operators used to offer it, but now it doesn't.
If you are interested, you can try ipv6 to test.
the last one is to use tools such as ngrok or frp for intranet penetration.
**Benefits of using intranet penetration:**
Free intranet penetration services such as ngrok, the URL generated by each run is not fixed, and there are some limitations, such as a new URL will be generated after a certain period of time, which is enough for testing.
Of course you can purchase the service of this tool, which provides fixed URLs and supports https.
**Shortcoming (same as the second one)**
**Suggestion**
The functional implementation is the same as the second suggestion, and the physical devices used by the website are all their own. The intranet penetration tool (ngrok, or frp) solves the problem of not having a fixed IP, providing a URL that you can access.
There are few users and the demand for web services is not high, so it is recommended that individual users or small business users use ngrok and frp in this scenario. Generally suitable for OA use in small businesses.
We are creating a server-side agent which periodically fetches data from nodes and maps this data to cumulocity measurements, events.
What is an elegant approach for hosting and/or packaging such a server-side agent?
We are hosting our own instance of the Cumulocity platform.
It's preferable to keep this server-side agent as 'close' to the core platform as possible, e.g. share some core agent framework dependencies.
We'd like to limit the amount of setting up additional environments or containers (e.g. Tomcat).
Cumulocity uses Karaf, would it make any sense to deploy the server-side agent into Karaf as a bundle?
Is there any recommended approach for hosting server-side agents? Does the cumulocity platform offer an alternative to deploying the agent to some "own environment"?
The Cumulocity examples repository contains the "tracker-agent" server-side agent example, which is an embedded tomcat Java application. There is little information about the intended deployment location.
I don't recommend deploying agents/microservices directly into the core Karaf server, since that endangers the resources available to the core APIs and is not supported. (I.e., will likely be overwritten with the next upgrade...)
Typically, people just provision an additional VM or docker next to Cumulocity to place their agents/microservices in. On top of that, we, for example, often use Spring Boot, so the effort is pretty low (java -jar ...).
We do have a hosting system for agents/microservices and will make that generally available also for others to use in Q1/2018. Follow the announcement channel at https://support.cumulocity.com to stay posted...
Possible ways to accomplish it:
Creating dedicated WCF service for this purpose (currently my favorite option)
Using the REST API?
Azure PowerShell?
Explanation:
Publishing a web-role cloud-service takes about 10 minutes. It's much too long during development - I try to do as much as I can offline, unit-test-ish and modular, but it's just impossible to completely avoid development cycles altogether with the VM.
Apparently, the long time is mostly a result of the machine being wholly restarted, so I'm trying to find an automatic solution, like uploading and installing the binaries.
What is the best way to accomplish it?
What do you think? would it cut at least 50% of the publishing time?
Do you expect any critical problems?
The solutions proposed below are definitely against best practices and should NEVER-EVER be used in production environment.
If your objective is to quickly test your changes in your development environment, there are two ways you can go about it.
Enable RDP and copy your modified binaries or other files directly in the appropriate folders on the VM. You could enable Remote Desktop on your web role and copy the files manually in appropriate folders.
Use Web Deploy: This will only work for web roles in your project but you could enable Web Deploy on your Web Roles and use that to make faster deployment. Please see this link for more details on how to use this feature: https://msdn.microsoft.com/en-us/library/azure/ff683672.aspx.
I have webspace and I was thinking of setting up a git repository on it.
If I am developing software and I want to host a repository (CVS, SVN, git, etc) online, is there any reason not to use a standard web hosting provider (GoDaddy, etc) to do this?
I'm thinking in terms of security, reliability, etc.
One reason for not using a standard-company is that usually shell-access is needed to setup a Version Control System (VCS). Many providers don't give shell access on normal webspaces.
When you are developing open-source software I'd recommend hosting at SourceForge, github, Google Code or similar providers, as your code is public there, you will get an issue tracker and several other tools that may help you. On github for example adding more developers to your project is very easy.
When you are developing closed-source software you still can use github, this gives you the same advantages as mentioned above, but of course it costs you a few bucks a month. Open-Source projects are free.
So while there is no real reason to not use standard hosting providers there are good reasons to use a company dedicated on hosting code.
As you asked especially for security: github (I use it as an example, as I host my code there as well) gives you a full list of information of what they do to ensure your code is safe.
My research and development environment calls for a heavily customised TRAC with a corresponding subversion repository and a binary file store (e.g. WebDAV).
I have my eye on at least 10 plugins that I would like to use (from integration with time tracking software, to specialist mathematics/code rendering). I'd also like to write my own plugins.
I am looking for a commercial host that will allow me to self-manage my TRAC plugins. I've looked into (and contacted) a few of the commercial providers from the TRAC Commercial Services list, including:
Project Locker
Repository Hosting
SVN Repository
Project Locker have described that they do a code review of plugin requests and handle it on their end (unspecified time period). Repository Hosting have said that they "will probably not add support for that in the near future". SVN Repository have said "you won't be able to install any new plugins" and have suggested one of their VPS accounts instead.
Short of managing my own VPS or dedicated server, does anybody know of a commercial SVN/TRAC host who allows paying customers to install their own plugins? I would have thought a chroot environment would have made this a no-brainer!
(Note: this was originally posted on programmers but was down-voted and I was advised to move it here. Quoting from their FAQ: implementation issues or programming tools (ask on Stack Overflow instead))
You'll probably find a hard time finding what you're looking for because as Craig mentioned in his comment, the concept of commercial hosting services typically revolves around limiting a customer's ability to customize. Keeping things relatively uniform means that the hosting company can manage systems and deploy automated updates much more easily and won't have to worry about their scripts breaking because of something odd that one customer installed or re-configured.
If you want to be able to install and configure plugins at will, I highly recommend going the VPS route and managing the server yourself. It's easier than you might expect (I was thrown into this situation and was pleasantly surprised). You can start with something like the Bitnami Trac stack, which is a virtual machine image that has a Linux OS plus Trac and all of the support tools (database, webserver, etc) set up and ready to go. If you use that as a starting point, all you should have to do is customize your Trac settings and install your plugins.
If you really don't want to have anything to do with the management aspect, remember that you can always go the VPS route and contract out the administration work separately. It might be easier if the hosting provider and the system admin come from the same company, but it's not a requirement. Given the flexibility and customization that you need, this might be a more realistic option.